[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 22:26:40 +0100

Mark Phippard wrote:
> 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.
>

So you're never confused by "svn log" not showing changes more recent
than those in your WC? That being just an example of the problem and not
at all grasping at straws.

> 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.
>

That is a logical position for someone who's focused on SVN as an API.
An SVN client is not an API, it's a user interface. Anyone who's ever
dealt with usability will tell you that in this context the definition
of "consistent" and "obvious" may be quite different from yours. What
works best in a UI is often not obvious at first; I can't remember if I
had reservations about the defaults when peg revisions were introduced,
but I do have now that we've been using them for a few years.

Like in your example from a few posts earlier, about getting revision
and path from "log -v"; I was quite surprised that you focused on one
file; the case I see used most often is finding some a bunch of related
changes on some possibly non-existend branch by doing an "svn ls -v
http://repos/branches" and picking the branch name from what's in the
"-v" part of the log output.

-- 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 22:26: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.