[darcs-users] sugggestion on command naming

[David Roundy]

[Quoted comments have been reordered...]

On Wed, Mar 10, 2004 at 12:04:24AM -0800, Adam Megacz wrote:
> 
> The "darcs push" and "darcs push --and-apply" distinction is a bit
> confusing... especially since they have (almost) the same heading in
> the manual!

I just took a look at the manual section on the push command, and
discovered that it is abominable.  :( I've also renamed the "Push and
apply" section to "Push and apply manually", which I think is more clear.

> How about making a seperate command for push-but-dont-apply?

I can see that a "sendpatch" command for emailing patches would be more
intuitive than a push command that sometimes emails patches, sometimes
saves them to files, sometimes uses ssh to run a darcs command (possibly
using a different version of darcs) on a different computer, sometimes uses
sudo to call darcs apply as a different user, etc.  But I'm not sure what
your suggested replacement does.  It looks like two of your commands don't
work...

>   darcs push
>   darcs push foo.com:/darcs/project

These two are fine, except that I guess the first one will only work if the
default repo is either an scp-style URL or a local directory.

>   darcs push repo at foo.com
> 
>   darcs sendpatch repo at foo.com

First, these won't work because you haven't specified a target
repository... unless you mean that the target repository has to be the
default repo when emailing? Without a target repository, there's no way to
know what the context of the patch needs to be, which would mean either
guessing via some heuristic, or trying to create patches having minimal
context.  The former would lead to nasty bug reports when the heuristic is
wrong (which it will be, sometimes), and the latter is *way* more
computationally expensive than you want to even consider, when repository
histories become even moderate-sized.  I think these commands should really
should be something like

darcs push --to repo at foo.com http://foo.com/repodir

darcs sendpatch --to repo at foo.com http://foo.com/repodir

Secondly, what is the difference between the two? I think you're imagining
that the first one will be "automatically" applied, but that isn't
something that darcs does.  That's the business of the recipient of the
email.  There's no (sane) way to control what someone else does with a
patch I send them via email.  Which means your commands have been reduced
to

darcs push
darcs push foo.com:/darcs/project
darcs sendpatch --to repo at foo.com http://foo.com/repodir

darcs sendpatch

where the first (a plain darcs push) doesn't work for repositories that are
accessed via http, and where I've added a fourth (darcs sendpatch with no
arguments) to do what the first currently does.  We *could* have darcs push
choose to send a patch via email if it has no other choice, but that starts
getting ugly, since there are then two commands that do the same thing
(send a patch via email), and either they'd have to be identical or there
would be subtle differences that would trip users up.

> I think this [sending patches via email] is the rare case (most of the
> time when you're pushing, you want to apply).

Well, as someone who has almost never used --and-apply (really only for
testing purposes), I don't agree with this.  It all depends on how your
infrastructure is set up.  --and-apply only works if either both repos are
on the same machine (certainly not the common case) or the repository is
accessed via ssh.  It also has the disadvantage (which is why I don't use
it) of being synchronous, so if you want a test suite to be run you have to
wait while it is run.

I think I may have an idea that will address some of your concerns without
adding an additional command.  One thing you want (correct me if I'm wrong)
is to be able to simply push to a local or ssh repository and have it act
(almost?) exactly like a pull, only backwards.  This certainly is implied
(intentionally) by the name "push", and is quite a reasonable case.  The
problem is that a very common case is that repositories are accessed by
http, and in this case there is no way to apply the patch, so the current
behavior (or something like it) is required.

I have two ideas as to how one might get around this, both of which are a
bit ugly, so perhaps you can suggest something better.

One is to make push simply check whether the target repository is local or
accessed via scp, and in either case, go ahead and apply the patch.  One
problem is that just because the repo is local or accessed via ssh doesn't
mean that we have write access, so we'd have figure out how to do something
reasonable if we don't have write access.  Another is that this means what
appear to be identical commands will behave differently:

darcs push http://abridgegame.org/repos/darcs

will be very different from

darcs push abridgegame.org:/var/www/repos/darcs

even though they look like they're just using different protocols to do the
same thing.  Yuck.

Another option would be to make the default behavior determined by the
target repository configuration, much as currently is the case with
_darcs/prefs/email.  The target repository could have a
_darcs/prefs/applyas containing the username to apply as.  Then any push as
that user via ssh (push targetuser at wherever) or local pushes when you
actually are that user, will automatically be applied.  The only catch is
that darcs won't know whether to try using sudo to switch users, since it
has no way of knowing if sudo is configured to allow applies as that user.
It could try, just to see if it fails, but then we start getting into the
realm where an error could change darcs' behavior instead of being
recognized as an error.  So I guess the _darcs/prefs/applyas method could
be used then to do --and-apply automatically, but not --and-apply-as.
-- 
David Roundy
http://www.abridgegame.org