[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-21 17:08:47 CET

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

This is an archived mail posted to the Subversion Dev mailing list.