On Thu, 2008-11-27 at 01:49 +0100, Branko Čibej wrote:
> The proposals I'm making come from some years of observing otherwise
> quite brilliant programmers breaking their heads against SVN and peg
> revisions. They're not necessarily a personal preference. This is not
> about my opinion vs. yours, it's about things I've observed vs. the
> current status quo.
Having read the whole conversation, I have the following observations:
* The usability issue seems to be especially relevant to legacy users
who are used to saying "svn cmd -r REV URL" when they want (in the
current usage model) "svn cmd URL_at_REV". I sympathize, but if we change
the default now, we'll just be creating pain for the people who used svn
between peg rev introduction and now.
* You get to see all the times someone tried to use "svn cmd -r REV
URL" and it didn't do what they wanted. You don't get to see all the
times someone tried to use "svn cmd -r REV URL" and it did what they
wanted. If the default changes, you'll suddenly get to see all of those
cases instead, after you break them.
* To some extent the situation is just inherently confusing. Only CVS
and RCS get away with being simple in this department, because they punt
on versioning tree changes. Any default is going to confuse some people
because they simply don't think (at first) about the fact that "COMMAND
on URL at REV" can have two different meanings.
* I work with a lot of brilliant programmers. They're just as
problematic as users as non-computer people, if not more so, because
they have trouble adapting to software which doesn't fit their mental
models. (Me too, whether or not I'm brilliant.) You can't just say
"this software wasn't intuitive to a brilliant person, so it must be
completely unusable to normal people."
* The "svn log wcfile" problem is totally separate. The peg
revision--the identity of the resource to show the history of--is
correctly chosen. The operative revision range is non-intuitive. It's
a moderately tricky problem because the WC resource might not exist any
more at HEAD, and (with our current implementation guts) we can only
trace history backwards from a known point.
---------------------------------------------------------------------
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-28 07:21:25 CET