Julian Foad wrote:
> Neels J Hofmeyr wrote:
>> *Talking about commandline keywords. Nothing to do with wc-ng:*
>>
>> It looks to me like Julian thinks "@BASE" currently means "the thing I
>> checked out", and I always thought the same. Julian, would you like to
>> confirm / dismiss my impression of what you think?
>
> Correct - that's what I thought. Now that you have pointed out that "cat
> -r BASE" doesn't behave like that - and we don't know how many commands
> do or don't - I might change my mind.
>
> (I keep saying "what about the other commands?". 'cat' and 'diff' are
> important but 'export' and 'merge (from)' and 'copy (from)' and
> 'proplist' and the rest need to agree too.)
Starting from 'svn help', I see these commands where @BASE is applicable:
blame (praise, annotate, ann)
cat
copy (cp)
diff (di)
export
info
list (ls)
log
merge
mergeinfo
move (mv, rename, ren)
propdel (pdel, pd)
propedit (pedit, pe)
propget (pget, pg)
proplist (plist, pl)
propset (pset, ps)
switch (sw)
update (up)
But I'd like to note that it's unlikely that any of these correlate @BASE to
the revert-base. AFAIK 'cat' uses the same API as the other commands to
resolve "@BASE" (which is parsed to svn_opt_revision_base).
As Bert said, only commit and revert so far use the revert-base at all, and
that is not based (argh) on the keyword "@BASE".
Disclaimer: I don't know for sure though, a check wouldn't hurt (except
being quite boring probably).
>
>> In fact, "@BASE" currently means "the to-be-committed node's history's tip".
>> (See attached short test script and output from trunk.)
>
> Would you mind extending your script to test the other commands? As I
Who, me?? ;)
> mentioned before, 'diff' supports both ways and I don't trust 'cat'.
Yes, I wouldn't depend on 'cat' either, but 'cat' was the easiest way to
show what I wanted to show.
Regardless, I think both ways are valid, for all commands in question:
That a user wants to {see the diff against|export|cat|...} the original
revert-base, or that a user wants the to-be-committed-node's "newer base".
<rant>
For example, when looking at your local mods with diff (just diff now), it
*can* be nicer to *not* see a replaced file's "- - -" lines in the diff. But
when you want to see how the replacing file differs from the replaced file,
you specifically want to see the differences between those. You could argue
that when replacing, the two versions shouldn't be structurally similar
anyway -- which I'd question, but even if: What if someone replaced by
accident and wants to see what's going on? Running svn diff on the replaced
and then unmodified file *shows empty* even if the replaced file is
completely different from the replacing file! That is an intuitive
catastrophe for that particular user and "he will break everything in the
wake of the false impression that the two contents are the same". IMHO
having a lot of "- - -" lines for the replaced file is less dangerous and
more accurate. In Bert's opinion (just guessing now!) it's dumb to have the
replaced file involved in the diff. I'm trying to showcase that every
command has this duality and desperately needs clarification anyway.
So I say we definitely need another keyword and then document both of them
properly. Oh, you agreed with that already? Well, then... ;)
</rant>
Next, someone in this room (dev@) will test all the cases and then we decide
whether to add "@ORIG"/"@REVERT" or "@NEWBASE" (or any other names agreed
upon, of course).
~Neels
Received on 2010-01-29 17:21:10 CET