On Dec 10, 2004, at 1:54 PM, Bradley Schick wrote:
>>> I still wonder why making -rPREV be the previous change revision
>>> wouldn't be a better solution.
>>
>> There's a design tension between these goals:
>>
>> - "optimize every command to behave differently, so that each
>> command can guess what the user really means", and
>>
>> - "define a bunch of concepts, and make them behave consistently
>> across all commands"
>>
>> You can't have it both ways, and the svn developers chose to go for
>> the latter goal.
>
> I was not suggesting special behavior for log. What I meant was; why
> not make -rPREV be mean "last changed revision" for all commands?
> When I say this:
>
>>> Since as you pointed out a file could not have changed
>>> between "COMMITTED-1" and the previous change revision, commands
>>> like diff would not be effected while log would work better.
>
> I mean: Wouldn't a different consistent behavior actually work better?
You and I have different definitions of "last changed revision". In my
r5, r10, r20 example, if COMMITTED == 20, then you want PREV to mean
15. But throughout all the subcommands, we've defined PREV to mean 19,
because the *contents* are guaranteed to be the same as r15. It just
so happens that this definition works well for all the commands but
'svn log', where the result isn't so intuitive.
The reason we defined PREV == COMMITTED-1 is because it saves network
round-trips. To get from r20 to r15, we'd have to ask the server to do
some history tracing and report the results. But maybe in svn 2.0 we
could switch to your definition instead. Maybe it's worth the extra
traffic...?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 10 21:08:51 2004