[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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 02 Dec 2008 10:57:52 -0500

Branko ─îibej wrote:
> C. Michael Pilato wrote:
>> No. We already have the case today that the working rev inherits from the
>> peg rev. Why? Because given the definitions of the things, that makes
>> sense most of the time. Your change adds a new behavior such that the peg
>> revision inherits from the working rev, but that's *exactly wrong* most of
>> the time.
> Hmmm. That seems to imply that most users (that I know) would be happier
> if -r were the peg revision and @foo the working revision ... i.e., just
> switch the meaning.
> In other words, way back when we added the right feature, but managed to
> complicate everyone's lives by causing it to change the apparent meaning
> of the command-line arguments.

Mmmm... close, but not exactly. As we've already seen in this thread and
previous ones, the "apparent meaning" differed from subcommand to
subcommand, from user to user, from need to need. It is absolutely the case
that long ago, we solidified the syntax into something that meant the same
thing every single time you used it. That had the effect of changing the
meaning of some invocations in incompatible ways, and we acknowledged that.
 But that was years ago, and the adoption of Subversion has vastly
flourished since then. It would be foolish to punish now *many* more users
*again* for such a change. You only hear about it when users get it wrong,
yes? If we estimate that there are something like 2 - 3 million Subversion
users, what percentage of those appear (from our admittedly limited
perspective) to be suffering from this syntax today?

C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-12-02 16:58: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.