[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: RFC: Untangling the peg revision knot (was: A preliminary study of non-contiguous transformations in the Hilbert space of Alexandrian solutions)

From: Branko Čibej <brane_at_xbc.nu>
Date: Wed, 26 Nov 2008 20:19:36 +0100

Branko Čibej wrote:
> C. Michael Pilato wrote:
>
>> Branko Čibej wrote:
>>
>>
>>> I think it's time to admit that defaulting all peg-revisions to HEAD was
>>> a horrible mistake;
>>>
>>>
>> What are you talking about? We default URL peg-revisions to HEAD,
>>
>
> Which is sometimes quite unexpected. I and dozens of people I know, none
> of them complete idiots, get burned by this default all the time.
>
>
>> and
>> working copy path peg-revisions to BASE. What's surprising about that?
>> Please tell me the rest of your mail wasn't based on this bogus assumption
>>
>
> Nope. :)
>
> I already posted an example of an IMHO wrong default for the URL_at_HEAD
> case. Now here's one for the WC_at_BASE case:
>
> svn log
>
> This doesn't show commits newer than the BASE of the current directory
> -- *even* if the latest commit was yours but happened not to bump thad
> directory's BASE. Now if that isn't an unexpected default, I don't know
> what is.
>

And to follow up a bit to myself ... I'd be tentatively prepared to
agree that from an API perspective, the current defaults may be sane.
But people don't get burned by the API, they get burned by the behaviour
of the tool.

I considered *not* proposing to rev the svn_client_* functions to change
their defaults; however, from the point of view of consistency between
different clients, that seems to be the prudent thing to do.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-26 20:19:56 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.