[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 'svn revert' vs. 'svn resolve'

From: <cmpilato_at_red-bean.com>
Date: 2003-06-10 17:48:11 CEST

Ben Collins-Sussman <sussman@collab.net> writes:

> Greg Hudson <ghudson@MIT.EDU> writes:
> > On Tue, 2003-06-10 at 05:57, Michael Andersen Nex° wrote:
> > > 'settle' is terse, it is semantically very close to 'resolve' and, finally,
> > > it isn't easily confused with other svn subcommands.
> >
> > +1
> >
> > (Though I'd still be okay with "unconflict" as well.)
> Well, other than me, Karl likes "settle" as well. That's a total of
> four people who like "settle" so far. Anyone actively against it?

I'm not actively against it -- which is to say I won't lead a campaign
to have it struck down. I just think of cereal boxes when I see it
("Contents may have settled during shipping.")

But the more I think about this molehill-turned-mountain, the more I
feel like we should have never gone down this road in the first place.
People are gonna screw up no matter what -- I *am* one of those folks
who has accidentally interchanged 'ls', 'cp', 'mv' and 'rm' at the
command-line. Sometimes things just happen. "Resolve" really was the
best possible choice of a name for that command, IMO. Anything else
suggested so far seems awkward ("unconflict", "deconflict") or
non-intuitive ("settle"). And, as was also asked previously, does
this mean we outright will never have another subcommand that starts
with "re"?

Whatever. A hard -1 on anybody touching the 'svn revert' command
except to add some sort of prompting, and +/-0 on 'svn resolve'. I
wash my hands of the issue -- I am, after all, Pilate-o.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 10 17:49:15 2003

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.