Re: Revision 2 [was Re: [PATCH] Fix for Issue #1093 (pre-release)]

C. Michael Pilato wrote:
> Shlomi Fish <shlomif@vipe.technion.ac.il> writes:
>
>>I suppose. I have some understanding of it, but don't know if it's the
>>same as yours.
>>
>>As for the UI I suggest having a --base-rev REVISION flag to specify "X"
>>here. I'll go with it for the while, as we can easily change it later.
>
> Nah, that would just complicate things further. My suggestions:
>
> 1. Make the --revision (-r) option *always* talk about the operative
> revision range. That means no more 'svn foo -rM:N path1 path2' as
> an alias for 'svn foo path1@M path2@N' (thankfully... what a
> stupid overloading of a concept that was...)

Yay! +1.

> 2. Make the '@' syntax always talk about the "peg" revision.

Yes.

> 3. The peg revision must always be greater than (younger than) the
> youngest revision in the operative range.

(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
Item's life*: A..=..=..M..=..=..D

-r3:6 item@2 @ ---------- 5(M) Modification
-r3:6 item@4 ----@----- 5(M) Modification
-r3:6 item@6 ----------@ 5(M) Modification
-r3:6 item@7 ---------- @ 5(M) Modification
-r3:6 item@8 @ Err: no item@8 Err: no item@8
-r1:3 item@2 ----@-- 2(A) Creation
-r1:6 item@2 ----@----------- 2(A) 5(M) Creation
-r1:9 item@2 ----@-------------------- 2(A) 5(M) 8(D) (no output)
-r3:9 item@2 @ ------------------- 5(M) 8(D) Deletion
-r6:9 item@2 @ ---------- 8(D) Deletion
-r1 item@2 - @ (no output) n/a
-r2 item@2 -@ 2(A) n/a
-r3 item@2 @ - (no output) n/a
-r8 item@2 @ - 8(D) n/a

Item's life*: A..=..=..M..=..=..D
Revisions: 1 2 3 4 5 6 7 8 9 Log output Diff/Merge

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
> commands with things like 'BASE' or 'WORK' or 'HEAD'. So things like:
>
> svn diff -rM:N wcpath
> svn diff -rM:N repos-url
>
> would do what you expect because under the hood it gets translated to
>
> svn diff -rM:N wcpath@BASE
> svn diff -rM:N repos-url@HEAD

+1.

> This gives you tons of flexibility. Say you want to see the diffs
> between revision 19 and 30 of a path that has been replaced by
> something else in HEAD of the repository. Well, you know the thing
> you want existed in revision 30, and you don't want to pick the
> history line that exists in HEAD, so you do:
>
> svn diff -r19:30 repos-url@30
>
> If you wanted the history of the thing now in HEAD between those two
> revisions, you could omit the '@30'.

Yes, but what if it was deleted in r30?

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 29 23:11:08 2003