Opened 16 years ago
Last modified 4 years ago
#7744 new defect
source:path@rev targeting a file below a copied dir may fail
Reported by: | Christian Boos | Owned by: | |
---|---|---|---|
Priority: | high | Milestone: | next-major-releases |
Component: | version control/browser | Version: | 0.11-stable |
Severity: | minor | Keywords: | svn newcache |
Cc: | itamarost@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
… 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
Attachments (0)
Change History (9)
comment:1 by , 16 years ago
follow-up: 5 comment:2 by , 16 years ago
Priority: | normal → high |
---|
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>
comment:3 by , 15 years ago
Milestone: | 0.12.1 → 0.12 |
---|
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).
comment:4 by , 15 years ago
Milestone: | 0.12 → next-minor-0.12.x |
---|
comment:5 by , 15 years ago
comment:6 by , 15 years ago
Cc: | added |
---|
comment:7 by , 13 years ago
Keywords: | newcache added |
---|---|
Milestone: | next-minor-0.12.x → next-major-0.1X |
comment:9 by , 9 years ago
Owner: | removed |
---|
This also happens for restricted changesets, see for example ticket:7648#comment:3.