Re: Revision 2 [was Re: [PATCH] Fix for Issue #1093 (pre-release)]
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2003-10-29 23:11:44 CET
C. Michael Pilato wrote:
> 2. Make the '@' syntax always talk about the "peg" revision.
> 3. The peg revision must always be greater than (younger than) the
(You mean "younger or equal", judging by your example below.)
Why must it? Are you saying that because it is difficult to implement forward tracking? I'm not sure that that restriction is acceptable from a use-case point of view.
There is a problem in the current implementation that will remain if you enforce that restriction: it is not possible for a revision range to span the end of an item's life. If "foo" was created in r10, then deleted in r20, I want to be able to see the log up to r20, but "foo" doesn't exist in r20 so "svn log -r10:20 foo@20" fails. (Currently, "svn log -r10:20 foo" fails.)
The new syntax should be able to overcome this difficulty. It should be possible to specify as the "peg" any revision in which the item existed (and in which I happen to know the path to the item). Then I should be able to specify a revision range that is before, including or after the peg revision. The revision range should also be allowed to cover the beginning and/or end of the item's life.
Here are several examples of the combinations that I would want to work, in ASCII graphics. I am assuming but not explicitly showing that the item may be renamed or moved during its life, so path/to/item@2 may not be the same as final/path/of/item@7. The user may know one of those paths but not the other(s).
Revisions: 1 2 3 4 5 6 7 8 9 Log output Diff/Merge
-r3:6 item@2 @ ---------- 5(M) Modification
Item's life*: A..=..=..M..=..=..D
In daily use we are normally dealing with items that have not yet been deleted, so some of these use cases are not often thought about.
If it is very difficult to implement the code to follow the history forwards, then we will have to decide whether it is acceptable to I suppose this could be left as a "not yet implemented" case, as that problem already exists in the current implementation.
* Note that I have shown the item's life-events offset from the revision numbers, to emphasise that they happen between revisions.
> The "peg" revision is the one that is auto-populated in various
> This gives you tons of flexibility. Say you want to see the diffs
Yes, but what if it was deleted in r30?
This is an archived mail posted to the Subversion Dev mailing list.