[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 14:41:22 -0500

On Wed, Nov 26, 2008 at 2:31 PM, Branko ibej <brane_at_xbc.nu> wrote:

> I don't buy that. The most common use of "svn ls -r" and "svn co -r" has
> been to get at code from obsolete and now-deleted branches. Your second
> argument about renames doesn't fit either; yes, you may know that some
> ancient thing was renamed, but it's a lot more likely that you *don't*
> and happen to know the old name, or know it was renamed but aren't sure
> of the new name. The @HEAD default only makes sense if you know just the
> new name and not the old one. From my experience, based on the
> vocabulary if interesting new phrases I've learned over the years from
> people trying use those commands, I'd say that last it by far the least
> common use case.
> (The usual way to get both URL and REV are to do an svn log -v, find the
> set of commits you're looking for, and copy rev and path from there,
> never caring about later deletions or renames or whatnot.)

Sorry, but I am still in disagreement. Your example just further
solidifies that. Let's use your example. I am naturally working in
HEAD and I run svn log -v to look at history. I see some old
interesting revision that I want to see more details about. You now
want me to also notice that somewhere in the history of the item the
name of the item has changed and use that new name when I use
subsequent commands. I'd typically assume the filename had not
changed and would get a failure.

>> There are always examples where each of the possible defaults makes
>> more sense to a user. I think having a policy where the default is
>> consistent and predictable is defensible and makes sense.
> I challenge you on the "predictable" part from the point of view of the
> common or garden user who's not acquainted with the code or the
> intricacies of the peg-rev algorithm.

I think you are confusing "predictable" and "expected". You are
saying a less experienced user would "expect" a different default. I
understand that argument. My only counter is that there will be cases
where different users "expect" the other default.

"Predictable", at least to me, means that once I get a general
understanding of how this feature works I can predict how it will
behave. I should not need to remember that someone decided that ls,
cat, blame and log might all have different defaults for this.

Mark Phippard
Received on 2008-11-26 20:41:31 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.