[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 15:59:58 -0500

On Wed, Nov 26, 2008 at 3:50 PM, Branko ibej <brane_at_xbc.nu> wrote:
> Mark Phippard wrote:
>> On Wed, Nov 26, 2008 at 3:25 PM, Branko ibej <brane_at_xbc.nu> wrote:
>>> I wonder if it would make sense to do a survey on the users@ list about
>>> this. I prophesy that most responses would be either "what's a peg
>>> revision?" or "yes, I get bitten by that all the time."
>> I'd say that understanding a 2-dimensional namespace is going to be
>> complicated no matter what we do. We can argue whether the default
>> should be HEAD or the operative revision, but I think having the
>> default change based on the command or other options would just make
>> it more confusing to users.
> That all depends on how one defines "consistent" and "predictable",
> doesn't it? For example, our current definition includes "for WC paths,
> the default is @BASE". Ah well then, does "svn log" with no parameters
> operate on a WC path? Technically speaking, it does; as a user, I see
> "svn log" as strictly repository-centric.

It feels like you are just grasping at straws now, because regardless
as to whether users EVER understand this feature or whether we decide
to change the default for URL's it will always make sense for @BASE to
be the default for a WC.

My position is simple. It is easy for two users to have differing
opinions on what the best default is when dealing with URL's and to
say one is right and the other is wrong is just silly. I would not
care if we had chosen some different default, but I do believe that
the default should be consistent regardless of the command.

Mark Phippard
Received on 2008-11-26 22:00:11 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.