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_at_host1/path/to/repo/path svn://u2:p2_at_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_at_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 <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Wed Feb 21 17:09:21 2007