You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Malcolm Rowe <ma...@farside.org.uk> on 2007/02/19 23:13:15 UTC
Re: svn commit: r23433 - trunk/subversion/svnsync
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.
Regards,
Malcolm
Re: svn commit: r23433 - trunk/subversion/svnsync
Posted by David Glasser <gl...@mit.edu>.
On 2/21/07, C. Michael Pilato <cm...@collab.net> wrote:
> All that said, I'm sure we could adopt the creds-in-the-URL syntax without
> too much trouble, if folks care enough.
Just make sure if you do that, it doesn't end up in the
svn:sync-from-url revprop :-)
--dave
--
David Glasser | glasser@mit.edu | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r23433 - trunk/subversion/svnsync
Posted by "C. Michael Pilato" <cm...@collab.net>.
Nik Clayton wrote:
> C. Michael Pilato wrote:
>> 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).
>
> This is probably an immensely stupid question, for which I apologise in
> advance, but...
>
> ... why not use the built in support for usernames and passwords in the
> URL specifications? Since a URL is supposed to look like
>
> <proto>://<username>:<password>@<host>/<path>
>
> (where the '<username>:<password>@' bit is optional) svnsync shouldn't
> need any explicit username/password operations.
>
> If one or both of the DEST_URL and SOURCE_URL for svnsync require
> usernames/passwords they can be specified at init time:
>
> svnsync init svn://u1:p1@host1/path/to/repo/path svn://u2:p2@host2/path/
>
> Right? And if DEST_URL needs a username/password pair that can be
> re-specified at sync time:
>
> svnsync sync svn://u2:p2@host2/path/
>
> Or am I missing something fundamental?
I suspect the history goes something like: There are 'svn' operations that
need auth creds but which don't use URLs (such as 'svn commit'). So the
'svn' program needed --username and --password options anyway. And why
introduce multiple syntaxes for the same thing? And why make svnsync's
syntax inconsistent with svn's?
All that said, I'm sure we could adopt the creds-in-the-URL syntax without
too much trouble, if folks care enough.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r23433 - trunk/subversion/svnsync
Posted by Nik Clayton <ni...@ngo.org.uk>.
C. Michael Pilato wrote:
> 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).
This is probably an immensely stupid question, for which I apologise in
advance, but...
... why not use the built in support for usernames and passwords in the URL
specifications? Since a URL is supposed to look like
<proto>://<username>:<password>@<host>/<path>
(where the '<username>:<password>@' bit is optional) svnsync shouldn't need
any explicit username/password operations.
If one or both of the DEST_URL and SOURCE_URL for svnsync require
usernames/passwords they can be specified at init time:
svnsync init svn://u1:p1@host1/path/to/repo/path svn://u2:p2@host2/path/
Right? And if DEST_URL needs a username/password pair that can be
re-specified at sync time:
svnsync sync svn://u2:p2@host2/path/
Or am I missing something fundamental?
N
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r23433 - trunk/subversion/svnsync
Posted by Malcolm Rowe <ma...@farside.org.uk>.
On Mon, Feb 19, 2007 at 08:26:58PM -0500, C. Michael Pilato wrote:
> 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.
>
Sounds good to me. I'd missed the fact that you'd deprecated the old
options.
Regards,
Malcolm
Re: svn commit: r23433 - trunk/subversion/svnsync
Posted by "C. Michael Pilato" <cm...@collab.net>.
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand