Sorry to be confusing. I didn't introduce the concept of pegged and
operative revisions, so I didn't explain them.
You correctly surmised that a "peg revision" is used to identify what
node we want to diff between two revisions (that's hand-wavy; see
below), and the "operative revisions" are the two revs we want to diff
between.
On Wed, 2003-10-29 at 20:59, Jack Repenning wrote:
> * "peg" is all about (indirectly) choosing the _node_ to which the
> operation applies, but choosing a _version_ based on some rules we
> suppose to be intuitive, and then selecting the node of which this
> version is a part.
That's mostly correct, except that a node can have many incarnations
within a single repository revision, even many incarnations with the
same copy-ID. So I don't think you ever get to throw away any
information about what node-revision you're hanging onto.
The important thing is, given a node-rev, we know how to go backward and
(in limited circumstances) forward in time to a different repository
rev.
Incidentally, you seem to be using your own terminology here, and that
can only lead to confusion. If you read libsvn_fs/structure, you will
find that we don't call anything a "version" except for the svndiff
version number. So when you're tempted to talk about "choosing a
version," instead say, "choosing a node-revision."
> I think I can similarly moosh a lot of our discussion about diff
> syntax into this: that it's very hard to keep revision info from
> leaking between "choose the node" and "choose the versions within the
> node."
I can't understand this, again because you're using your own
terminology.
> > 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),
>
> This seems once again to muddle "find the node" and "pick the
> versions," doesn't it?
No, just because the default ending rev is the same as the fixed peg rev
doesn't mean I'm muddling them together.
> * as argued elsewhere, I want "-rM[:N] TARGET@PEG-R" back, to
> preserve their separation
If you'd read forward in your email, you'd see that you have it. :) But
it's not a matter of "preserving their separation"; just because the
default end rev was the same as the fixed peg rev doesn't mean that my
proposal didn't keep them separate.
> > diff --old=OLD-TGT[@OLDREV] --new=NEW-TGT[@NEWREV] [PATH...]
> >
> >Compare OLD-TGT and NEW-TGT, restricted to the paths PATH...
> Oops, sorry, I'm lost again. What's it mean, "compare X and Y,
> restricted to Z"? Is the idea that X and Y might be directories,
> that the comparison is implicitly recursive, that the path(s) are
> paths within (both?) X and Y, and so that anything in X/Y which is
> *not* named in the path-list should be ignored?
Yes.
> >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?"
>
> Uuhh ... an attempt to anticipate my very question, I think, but I'm
> not following the answer. Sorry. Maybe: "what's the complete diff
> command to ask this question?"
I'll change the question a bit: "what changes were made to libsvn_ra_dav
and mod_dav_svn between the 0.32 branch and the trunk?"
svn diff --old=http://svn.collab.net/repos/svn/branches/0.23
--new=http://svn.collab.net/repos/svn/trunk
subversion/libsvn_ra_dav subversion/mod_dav_svn
You might say, "gosh, that's some mighty complicated syntactic sugar
there, since it's just equivalent to two successive svn diff commands
with the paths tacked onto the old and new URLs." And you might be
right; the syntax made more sense back when we thought we could shoehorn
"svn diff foo bar baz" into it as syntactic sugar. So perhaps we should
forbid path arguments to the --old/--new case, which leaves us with:
svn diff --old=OLT-TGT[@OLDREV] --new=NEW-TGT[@NEWREV]
svn diff OLD-URL[@OLDREV] NEW-URL[@NEWREV] (syntactic sugar)
Now, you might say "why not just ditch the first syntax, and only
support the second syntax?" We could do that, but only if we're willing
to sacrifice the ability to diff two working copy paths against each
other, because "svn diff PATH1 PATH2" looks like the other use case
(i.e. "svn diff -rBASE:WC PATH1@WC PATH2@WC").
Alternatively, you might say "why not ditch the second syntax, and only
support the first syntax?" I'd be fine with that; it's a little more
verbose, but it makes it absolutely clear when you're comparing two
specified coordinates in version-space against each other, as opposed to
comparing a list of one or more things between two revisions.
> > 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,
> Err ... I can't fit those words into my understanding of "peg,"
> above. If I got that right, I need help through "perform a pegged
> diff of X between R1 and R2." Or maybe, I think *all* diffs are
> pegged, albeit some explicitly and some implicitly.
I'll work through what happens in the two cases, under my proposal.
Case 1: svn diff URL@R1 URL@R2
Find the contents of URL at R1; call that node-revision X. Find the
contents of URL at R2; call that node-revision Y. X and Y may be parts
of totally different nodes, even though they have the same URL. Diff Y
against X.
Case 2: svn diff -rM:N URL
Find the contents of URL at HEAD; call that node-revision X. Go back in
time from X to repository rev M; call that node-revision Y. Go back in
time from X to repository rev N; call that node-revision Z. Diff Z
against Y.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 30 03:54:45 2003