[darcs-users] Announcing darcs 1.0.4rc1

[David Roundy]

On Tue, Oct 18, 2005 at 04:11:39PM +0900, Stephen J. Turnbull wrote:
> >>>>> "David" == David Roundy <droundy at darcs.net> writes:
> 
>     David> On Fri, Oct 14, 2005 at 07:59:48PM +0930, Jonathon Mah wrote:
> 
>     > The current usage for this command is:
>     > Usage: darcs put [OPTION]... <REPOSITORY>
> 
>     > From that it is not clear that <REPOSITORY> is the location of a  
>     > _new_ repository. Something like <NEW REPOSITORY> would make it more  
>     > evident.
> 
>     David> Done.
> 
> It would be nice if this were consistent throughout.  In my notes to
> myself, as well as in naming arguments in scripts, etc, I consistently
> use "repo[sitory]" for an existing repository and "branch" for the new
> repository.  When both exist, it's "local" (what I've been hacking on
> most recently) and "remote" (archival or mainline).  I tried "source"
> and "target" (eg for push and pull), but that didn't work so well for
> me.

Indeed.  I liked the verbose <NEW REPOSITORY>.  For push and pull/send
<SOURCE REPO> and <TARGET REPO> seem good to me (or full <SOURCE
REPOSITORY> if it seems likely to fit on the line).  I'm not sure what
other possibilities there are, but if you take a look and make a proposal
for a consistent terminology, I'll look it over and let you know whether
I'd approve a patch making the change (before you go to the trouble of
looking at each and every command).

> This works for me, although I hesitate to recommend adoption by the
> project because others might put a different spin on words like
> "branch" and "local".

I agree.  I'd avoid "remote" since no darcs command really requires that a
repository be "remote", and terminology like "branch" are really
descriptive of use rather than function.  "local" seems okay, if the repo
really needs to be local.

> If a consensus appears in favor of some terminology, I'll make time to
> review the commands and cons up a patch.

As I say, if you propose a (hopefully conservative--or agreeing with a
subset of existing practice) terminology, I'll let you know if I agree with
it, and then you can go ahead and do this.

> I'd also like more consistency in the object-specification options.
> --patch works for everything I used, but IIRC the official names are
> longer and vary from command to command.  Similarly with --repo vs
> --repo-name, etc.  (I realize that last seems to be a distinction of
> existing vs. new, but that's too fine for me to remember at use time.)

The idea between --patch and --patches is to distinguish whether the match
will match a single patch or if it will match all patches that match.  I
think this is reasonable, but should perhaps be documented.

--repo vs --repo-name is like --patch vs --patch-name, the -name means
you're giving a new name, not a regexp that will match an existing name.
At least that's what it's intended to mean... if it doesn't work that way,
we should fix it.  I don't like the same command having different
behaviors.  For example, if you had just one repository, you might want to
stick in your ~/.darcs/defaults "ALL --repo /the/only/repo" so you could
whatsnew from whereever you are.  But it would be dissapointing if this
would mean that you always had to specify a second argument to get to avoid
getting the error message

darcs failed:  Directory or file named '/the/only/repo' already exists.

This is a rather contrived example, but I just don't like the idea of the
same flag name having different behavior for different commands.

Actually, removing the --repo-name flag from get entirely wouldn't be a bad
idea.  It's redundant with the more intuitive method of giving a second
argument to get.  I never use it, and wouldn't encourage anyone else to do
so... It dates from before get accepted a second argument.
-- 
David Roundy
http://www.darcs.net