[darcs-users] Command renamings and hide/show
will at glozer.net
Fri May 14 04:15:52 UTC 2004
Kenneth Knowles <kknowles at berkeley.edu> writes:
> I'll give my votes:
> On Thu, May 13, 2004 at 07:08:45AM -0700, Kevin Smith wrote:
>> >* Rename 'repository' to 'branch' throughout
>> I agree with the other poster that people have negative connotations
>> with branches.
> I like repository, because the word "branch" exists to distinguish it from
> "trunk" which would be the default. So "branch" implies an exceptional state
> to some degree, which is not the case in darcs.
I like repository too, I only use the word "branch" to explain things
to CVS users. When I am using darcs, every copy of repository is just
that, not a "branch". It would be very confusing and misleading to me
to have all of the --repo-* switches renamed to --branch-*
>> >* Make the default to be as verbose as possible, and offer -q /
>> Yes, probably.
> I like this, but don't feel strongly about it.
I don't feel strongly either, but I do think darcs already outputs
just enough information so you know what is going on without being
>> >* The default should be that no patch is deleted without a warning
>> I think so.
> I like this too, though overriding it would be necessary for scripting.
Maybe a preference to warn, it would bother me to see it all the time
when I already know what is going on.
>> >* It should be easy to temporarily get a patch out of the way,
>> I don't think this should be in 1.0.
> Whatever works for the maintainers. I've never had a desire to use this.
I haven't had a desire to use this either.
>> > get "branch" or "mkbranch", with explicit option --and-
>> I like having 'get' as a separate command from 'pull'. At least in my
>> mind, one creates a repo, but the other one adds to an existing repo.
> "get" is easy to understand and concise, I'm strongly opposed to
> changing it. I agree with Kevin's rationale as well.
I definitely do not want this to change, "get" means get. Some large
percentage of the time, a person getting a repo just wants a copy,
they don't intend to work on a "branch". If the command was "branch",
I would go looking for a "get"-type command.
>> > inittree "branch --root" or "branch --trunk" or just "trunk" or
>> initrepo or just init or initialize might be better.
I take advantage of darcs' command searching to just type "init" most of
the time, but I am happy with the full name too.
> I like just "init" because it is just as clear, and less characters :-)
> Also, you dodge the whore repo/branch/tree vocabulary mess.
>> > unpull "unrecord --and-delete" or something like that,
> I concur
I guess this would be ok, but unpull has a nice symmetry that I like.
>> > * send->export and apply->import: this has more symmetry, and removes
>> > the strange "send --output" combination.
>> Seems reasonable, but I don't have strong feelings about it.
> I too do not feel strongly about it. I think the intuition of "send" might be
> nice, but I've never used it.
I definitely dislike this change, "export" could mean anything that creates
a patchset that can be imported by someone else, I would not expect it to
"send" an email.
>> > * add->control and remove->uncontrol: this removes any confusion
>> > between "darcs remove" and "rm". (Or perhaps "ignore" instead of
>> > "uncontrol", but that has less symmetry.)
>> Archipel uses "track" and "untrack", which I like. But I'm not convinced
>> this needs to be changed.
> I strongly dislike this change. "add" and "remove" are nicely
> symmetrical, and its very common (and easy to deduce even if you
> didn't know before) that source control will leave a file even when
> it has relinquished control.
I strongly dislike this change as well, "add" and "remove" are a much
clearer explanation of what is going on.
Perhaps I am in the minority here, but from the very beginning I've felt
very comfortable with darcs' command set. The current commands are what
I would expect, and work as I expect. There is probably some room for
improvement, adding "send" was a great move, but I'm against a full scale
More information about the darcs-users