source:path@rev targeting a file below a copied dir may fail

[cboos]

... when the file has not been modified since the copy and rev predates the copy operation itself.

e.g. source:/branches/0.11-stable/contrib/bugzilla2trac.py@6820#L824
leads to:

No node /branches/0.11-stable/contrib/bugzilla2trac.py at revision 6820

Looking at source:/branches/0.11-stable/contrib/bugzilla2trac.py​ (without revision spec) works, and indeed shows a revision of r6820 for this file.

This is happening because at r6820, there was no branches/0.11-stable. This behavior is actually "correct" if ...@6820 is supposed to be a peg revision in Subversion terminology, but it's annoying nonetheless, as the TracLinks syntax doesn't allow an alternative way of specifying the revision(*) and anyway I don't think it's a good idea to expose the peg revision vs. operative revision subtleties in Trac (​http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html).

(*) well it does, but source:/branches/0.11-stable/contrib/bugzilla2trac.py?rev=6820​ has the same problem

[cboos]

This also happens for restricted changesets, see for example ticket:7648#comment:3.

[cboos]

Another related bug - annotate links don't work either, even when not specifying the version:

• source:/branches/0.11-stable/contrib/bugzilla2trac.py​ works
• source:/branches/0.11-stable/contrib/bugzilla2trac.py?annotate=blame​ fails with

  Warning: Can't use blame annotator:
    No node <requested_path> at revivision <created_rev>
  

[cboos]

Related to #3340, there might be another way to think about requested (path, rev) vs. (created_path, created_rev): we could introduce the (origin_path, origin_rev), which would correspond to earliest path and revision in which the requested (path, rev) appeared on that path (see fs.closest_copy usage in r8332).

In the example of this ticket, the link:

source:/branches/0.11-stable/contrib/bugzilla2trac.py@6820#L824

would remain incorrect, but one wouldn't be lured into creating such links as the web interface would never show a path like /branches/0.11-stable/contrib/bugzilla2trac.py with a revision in which that path doesn't exist (here r6820). Instead, it would display the revision in which that path first appeared (here r6940, the creation of the 0.11-stable branch).

[cboos]

Replying to cboos:

Another related bug ...

• source:/branches/0.11-stable/contrib/bugzilla2trac.py?annotate=blame​ fails

This particular issue was fixed by [8797].