On Thu, Mar 09, 2006 at 01:19:03PM +0000, Julian Foad wrote:
> Malcolm Rowe wrote:
> >>That's wrong. In this section, according to the comment, we should
> >>assign pegged_diff=TRUE unconditionally.
> >
> >Nope; 'svn diff foo' is handled by that case too, and that's not a pegged
> >diff (though it looks like later code may may it pegged @WORKING, which
> >may work anyway). I think it only wants to be pegged if either revision
> >is 'non-local'.
>
> I disagree with you. Yes, "svn diff foo" is handled by that case. That
> means, "show me the difference between the base revision and the working
> pseudo-revision of this object". To me, that's a "pegged diff" because I
> think of "the working files" as being a revision of a sort, rather than
> thinking of this as a difference between one arbitrary tree and another
> arbitrary tree.
>
Okay, perhaps I have the definition of a 'pegged diff' wrong - what
exactly is it? I assumed, I guess, that it was one in which we needed
to follow history to get the name of the item at the operative revisions.
> different. I don't see the logic in saying that a diff is "pegged" only if
> at least one revision is non-local:
>
> diff foo@100 foo@200
> diff foo@BASE foo@200
> diff foo@100 foo@WC
> diff foo@BASE foo@WC
>
> Why should we consider just the last one to be non-pegged?
Perhaps because we don't have to determine what foo's name at the
operative revisions is? (assuming an implicit -rBASE:WORKING) But I
must admit that I'm reaching - I don't know the answer, and it may not
really matter because it...
> will go through to the same diff_wc_wc function in the end, whether we call
> it pegged or non-pegged at this stage.)
> A different way to ask the question is: given that the distinction between
> pegged and non-pegged diffs seems to affect only the user interface, is
> there any reason why we want a conceptual definition of it that excludes
> the BASE<->WC case?
>
I'm now struggling to understand what the difference is at the API level.
Hmm, lets see, svn_client_diff3() can answer 'diff -rX:Y path1@X path2@Y',
where 'path1' and 'path2' are URLs or wc paths, and X and Y are almost
any combination of revisions ('local': BASE, WORKING; 'remote': COMMITTED,
PREV, date, rN).
Hmm, the API documentation says "(Currently, @a path1 and @a path2 must
be the exact same path)", but that's not true, is it, because they're
different in the 'diff -rX:Y --old=path1 --new=path2' case.
On the other hand, svn_client_diff3_peg() answers 'diff -rX:Y path@PEG'
(note: one path only), and one of X or Y must be non-local simply because
diff_wc_wc() doesn't accept a peg revision (and what would it mean if
it did?).
[It does seem odd that we've got a separate set of interfaces for
'non-pegged diffs' rather than just passing svn_opt_revision_unspecified -
in fact, the non-pegged versions can be trivially implemented using the
pegged versions.]
Anyway, back to the question: yes, I think that there is a difference:
a 'pegged' diff implies that we need to go through some kind of
history-tracing to find the name of the items at the operative revisions,
and that isn't something we ever need to do for BASE:WORKING diffs.
> There are more bugs with pegged diffs. For example, the previous section
> of svn_cl__diff() handles the "[-rN:M] --old=TGT@PEG [--new=TGT@PEG]" case,
> but overwrites the "-r" revisions with the peg revisions rather than
> correctly looking the targets up at their peg revisions.
I _think_ that's correct, albeit bizarre. The help says:
2. diff [-r N[:M]] --old=OLD-TGT[@OLDREV] [--new=NEW-TGT[@NEWREV]] \
[PATH...]
2. Display the differences between OLD-TGT as it was seen in OLDREV and
NEW-TGT as it was seen in NEWREV. PATHs, if given, are relative to
OLD-TGT and NEW-TGT and restrict the output to differences for those
paths. OLD-TGT and NEW-TGT may be working copy paths or URL[@REV].
NEW-TGT defaults to OLD-TGT if not specified. -r N makes OLDREV default
to N, -r N:M makes OLDREV default to N and NEWREV default to M.
Notice that 'N' and 'M' don't actually have any part in the diff activity
other than providing defaults for OLDREV and NEWREV. Syntactical sugar,
nothing more.
(and while it might be nice to be able to do 'diff -rX:Y path1@A path2@B',
that's not something that our API offers).
Regards,
Malcolm
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 9 23:02:32 2006