RFC: Making only optional stuff optional in the svnsync command-line

["C. Michael Pilato" <cm...@collab.net>]

I've got some complaints about the synsync command-line that I think should
be be addressed before 1.4.0 is released.  And yes, I'm signing up to do
work resulting from this conversation.  The complaints mostly stem from the
idea that "options" should be optional (and that things that aren't optional
shouldn't be "options"), and they are as follows:

   For 'svnsync init', the SOURCE_URL should be an argument, not an
   option.  Let's drop --source-url altogether, and then argue for
   weeks about whether the syntax should be 'svnsync init DEST_URL
   SOURCE_URL' or 'svnsync init SOURCE_URL DEST_URL'.  (I plan to use
   the former, for consistency with other svnsync commands, and
   because the DEST_URL is the one getting init'ted.)

   For 'svnsync copy-revprops', if a revision is required (which it
   currently is), then there shouldn't be a --revision "option", and
   the REVISION should just be an argument.  However, I'm wondering if
   anyone has opinions about taking this a different way, namely, not
   requiring a revision and instead having some well-defined default
   value when no explicit one is provided.  My opinion is a
   two-parter: teach the program to honor revision ranges, and make
   the default be 0:HEAD.

Thoughts?

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

Re: RFC: Making only optional stuff optional in the svnsync command-line

[David Glasser <gl...@mit.edu>]

Garrett Rooney <rooneg <at> electricjellyfish.net> writes:

> >    For 'svnsync init', the SOURCE_URL should be an argument, not an
> >    option.  Let's drop --source-url altogether, and then argue for
> >    weeks about whether the syntax should be 'svnsync init DEST_URL
> >    SOURCE_URL' or 'svnsync init SOURCE_URL DEST_URL'.  (I plan to use
> >    the former, for consistency with other svnsync commands, and
> >    because the DEST_URL is the one getting init'ted.)
> 
> The main reason I made it an option was that I kept forgetting which
> URL came first.  If you want to change it feel free though, I'm
> perfectly capable of checking the help output when I forget.

This isn't *too* much of a problem in the current implementation, since assuming
both repositories aren't brand new, if you get it backwards you'll just get an
error message saying that the destination repository already has content in it.

(On the other hand, if we ever wanted to extend svnsync to work in cases where
the repository already has content (say, to allow svk-style mirrored subtrees)
this argument wouldn't hold. But that's not now.)

By the way, I hesitate to post yet another patch since you might be about to
rewrite the command anyway, but I missed one constraint in documenting svnsync
init: the source also has to be a repository root.

--dave

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: RFC: Making only optional stuff optional in the svnsync command-line

[Garrett Rooney <ro...@electricjellyfish.net>]

On 8/2/06, C. Michael Pilato <cm...@collab.net> wrote:
> I've got some complaints about the synsync command-line that I think should
> be be addressed before 1.4.0 is released.  And yes, I'm signing up to do
> work resulting from this conversation.  The complaints mostly stem from the
> idea that "options" should be optional (and that things that aren't optional
> shouldn't be "options"), and they are as follows:
>
>    For 'svnsync init', the SOURCE_URL should be an argument, not an
>    option.  Let's drop --source-url altogether, and then argue for
>    weeks about whether the syntax should be 'svnsync init DEST_URL
>    SOURCE_URL' or 'svnsync init SOURCE_URL DEST_URL'.  (I plan to use
>    the former, for consistency with other svnsync commands, and
>    because the DEST_URL is the one getting init'ted.)

The main reason I made it an option was that I kept forgetting which
URL came first.  If you want to change it feel free though, I'm
perfectly capable of checking the help output when I forget.

>    For 'svnsync copy-revprops', if a revision is required (which it
>    currently is), then there shouldn't be a --revision "option", and
>    the REVISION should just be an argument.  However, I'm wondering if
>    anyone has opinions about taking this a different way, namely, not
>    requiring a revision and instead having some well-defined default
>    value when no explicit one is provided.  My opinion is a
>    two-parter: teach the program to honor revision ranges, and make
>    the default be 0:HEAD.

I don't know about the 0:HEAD part (that's a lot of revprops!), but if
you want to change it from an option to an argument I have no problem
with that.

-garrett (who is glad that people are finally looking at svnsync long
enough to have comments about how its ui should work ;-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org