Re: Issue #1093: "svn diff" enhancement to follow moved/renamed items

[Added a description to the Subject line so we can see what these messages are about without having to read several paragraphs or fire up the issue tracker. :-) ]

This all sounds good. Some comments on the details follow.

C. Michael Pilato wrote:
>
> Folks may recall some debate about what do in the 'svn diff [-r X:Y]
> PATH-OR-URL[@Z]' situation when Z is < either X or Y. Since we can't
> trace history forward in time (and even if we could, there could be
> multiple choices of lineage to follow), I wanted to punt outright.
> And I got fussed at for that. Well, now I realize that we can at
> least assume that PATH-OR-URL hasn't been renamed between Z and the
> greater of X and Y. And we can reliable determine if our guess was a
> safe one by verifying that the path of the resource in Z is the same
> as the resource's path in the greater of the X and Y.

That sounds sound. Syntax 1 below doesn't allow Z to be specified, so, until syntax 1 is extended, this is limited to Z = WC. I would guess that this case would most commonly arise in the form "diff -rX:HEAD path", when the WC is not quite up to date.

> So let's talk about syntax changes. On Oct. 29, 2003, Greg Hudson
> proposed the following:
>
> 1. diff [-r M[:N]] [TARGET...]
>
> Each target may be a path or URL, but it is invalid to specify a
> URL with no -r option. Perform a pegged diff for each
> target. For paths, the default starting rev is BASE, the default
> ending rev is WC, and the peg rev is always WC. For URLs, there
> is no default starting rev (-r option must be present), the
> default ending rev is HEAD, and the peg rev is always HEAD.

Add: "The default target is the path '.'."

I think that "peg is WC" is exactly what we need, but just want to point out that it may be slightly trickier to implement than "peg is BASE". Shouldn't be a problem, though.

> 2. diff --old=OLD-TGT[@OLDREV] --new=NEW-TGT[@NEWREV] [PATH...]

The words "old" and "new" here match one common use case but are misleading in other cases. But that's a separate issue, and is already in the existing implementation.

Requiring both "--old" and "--new" to be specified in this case is stricter than the current implementation, but I think that is a good thing. It is always better to start strictly and have the option of relaxing the syntax later than vice versa.

Add: "Each of OLD-TGT and NEW-TGT may be a path or a URL."

Presumably we add: "Each of OLDREV and NEWREV defaults to HEAD for a URL or to WC for a local path." (The existing implementation defaults to BASE for local paths, but we probably came to the conclusion that WC is better.)

> Compare OLD-TGT and NEW-TGT, restricted to the paths PATH... if
> given. Can be used to answers questions like "what changes were
> made to libsvn_ra_dav between the 0.32 branch and the trunk?"
> (Limitation: if libsvn_ra_dav was renamed between the 0.32
> branch and the trunk, the user will have to go find out how; we
> can't answer complex questions like "what was the name of
> /trunk/subversion/libsvn_ra_dav under /branches/0.32?".)

We should clarify "restricted to the paths PATH..." with regard to that limitation. The current help says "PATHs, if given, are relative to OLD-TGT and NEW-TGT and restrict the output to differences for those paths." This is still not quite clear; I assume it means the union of PATHs that exist under OLD-TGT and PATHs that exist under NEW-TGT, with those that are only present on one side causing an "added" or "deleted" diff. Or does it mean that it is an error if any PATH does not exist on both sides?

> 3. diff OLD-URL[@OLDREV] NEW-URL[@NEWREV]
>
> Syntactic sugar for 'diff --old=OLD-URL@OLDREV --new=NEW-URL@NEWREV'.
> Easily distinguishable from the first usage because you can't
> use URLs without a -r option. Note "svn diff URL@R1
> URL@R2" is rather different from "svn diff -rR1:R2 URL",
> because the latter performs a pegged diff of URL@HEAD between
> R1 and R2, while the former looks up URL's pathname
> independently in R1 and R2 and diffs the results.
>
> None of these forms mix the -rX:Y and the @-syntax because Greg deems
> that stuff esoteric. For now, I'm willing to lay down and concede
> that. In my mind, though, the best benefit of that fact is that the
> command-line parsing code doesn't have a change a lick in order to
> handle these use cases (though, I think there is one de-unification
> I'd like to see, not directly related to this topic).

This seems like a nice clean syntax, and it leaves room to add support for "@PEG" on the TARGETs of syntax 1 so that deleted items can be referenced easily.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 11 01:57:25 2003