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

Re: svn commit: r38800 - trunk/subversion/svnsync

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 18 Aug 2009 17:32:05 -0400

Bikeshedding is a good thing when the homeowners' association has policies
regarding paint colors. (If I may be so bold as to torture that analogy
completely.) It was surprisingly difficult to choose a new option name that
fit, but the exercise was a good one to endure.

Greg Stein wrote:
> Thanks!
> Sorry.. didn't mean to bikeshed too hard on this, but I seem to recall
> that (during my time away) there was a groundswell against --force. I
> was echoing that, along with my own kneejerk against it.
> Thanks for reflecting on it, and switching over.
> Cheers,
> -g
> On Tue, Aug 18, 2009 at 20:44, C. Michael Pilato<cmpilato_at_collab.net> wrote:
>> Okay. Went with --allow-non-empty instead.
>> C. Michael Pilato wrote:
>>> Fair 'nuff. Will choose a new option name after lunch.
>>> Greg Stein wrote:
>>>> Didn't we already go through the discussion of "don't use --force
>>>> anymore" ?? ie. use a more descriptive option like
>>>> --overwrite-exist-revisions ?
>>>> The name --force is not descriptive of what it actually does. Which
>>>> means we need all kinds of supporting documentation to detail it. But
>>>> if somebody doesn't read the documentation and uses --force according
>>>> to an assumption of *another* meaning... they could run into
>>>> unexpected and disastrous results.
>>>> For the few cases where something like this would be needed, I have no
>>>> qualms making people type a long option name.
>>>> Cheers,
>>>> -g
>> --
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand

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

Received on 2009-08-18 23:32:25 CEST

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.