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

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

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-02-20 02:26:58 CET

Malcolm Rowe wrote:
> Hi Mike,
>
> Nice change. One question:
>
> On Mon, Feb 19, 2007 at 02:46:25PM -0800, cmpilato@tigris.org wrote:
>> + /* Disallow the mixing --username/password with their --source- and
>> + --sync- variants. Treat "--username FOO" as "--source-username
>> + FOO --sync-username FOO"; ditto for "--password FOO". */
>> + if ((username || password)
>> + && (source_username || sync_username
>> + || source_password || sync_password))
>> + {
>> + err = svn_error_create
>> + (SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
>> + _("Cannot use --username or --password with any of "
>> + "--source-username, --source-password, --sync-username, "
>> + "or --sync-password.\n"));
>> + return svn_cmdline_handle_exit_error(err, pool, "svnsync: ");
>> + }
>
> Is there any reason to disallow 'svnsync --username foo --source-password bar
> --sync-password baz'? I think the only think you'd have to change to
> allow it is this test, and possibly some of the help text.

Yes. I wanted to explicitly discourage folks from getting into the habit of
using a mixture of the old-style and new-style auth options.

As far as I'm concerned, --username and --password represent a design
oversight (for svnsync only, of course), and should be deprecated in favor
of the new, explicit options (and the usage message now indicates that they
are, in fact, deprecated). So my primary goal is to get folks to use the
four new, much-clearer options. Secondarily, I wanted to not break scripts
that might already be using the older options. However, allowing folks to
straddle the fence was not, in my opinion, desirable.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Feb 20 02:27:23 2007

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.