[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: Mark Phippard <markphip_at_gmail.com>
Date: Wed, 26 Nov 2008 10:27:08 -0500

On Wed, Nov 26, 2008 at 10:23 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> Greg Stein wrote:
>> Maybe I could apply some more thinking here, but my initial thought is
>> "fuck ya!". The peg shit screws me up. It was very disturbing to return
>> to svn to find that specifying old revisions didn't work at ALL like I
>> would expect. Dug in, and found the peg stuff. Agreed that it generally
>> doesn't work as expected.
> "Works as expected" depends largely on the expectations. I find that the
> peg revision algorithm works exactly as expected and intended. They certain
> work way better than before the peg revision algorithm was designed -- I
> mean, it was the chosen solution for a slew of real bugs that all users were
> hitting (not just those that didn't take the time to understand how to use
> Subversion).

I do not want to spend time thinking of specific examples, but I
recall when we have discussed this in the past that there are certain
commands where the expected default would be HEAD and others where it
would be the same as the operative revision. We decided it was better
for all commands to be consistent in the default rather than having it
vary for each command. Branko seems to be suggesting the latter.
That for each command we base the default on what the user is likely
to expect?

Mark Phippard
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 16:28:45 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.