[darcs-users] sugggestion on command naming
droundy at abridgegame.org
Thu Mar 11 13:12:38 UTC 2004
On Wed, Mar 10, 2004 at 05:14:30PM +0200, Tuomo Valkonen wrote:
> On Wed, Mar 10, 2004 at 09:15:12AM -0500, David Roundy wrote:
> > 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.
> Wouldn't it be simplest to consider the http case equal to where you don't
> have permissions to modify the repository? Given that darcs is interactive
> in many cases, I'd think the following behaviour would be quite good (the
> locations in brackets being entered on the command line or read from prefs):
> push [http://foo/bar]
> Unable to push. Press ^D to abort or enter email address [foo at bar]?
> push [foo:bar]
> Permission denied. Press ^D to abort or enter email address [foo at bar]?
> push --email
> push --email-to foo at bar
Hmmm. I guess the problem is that it seems to me that with a properly
configured repository, the email option should be the default. After all,
if someone wants to push patches to the darcs repository, email is the way
it is done.
I don't know though, I'm increasingly thinking that I like the current way
of doing things. It makes sense that darcs commands in a given repository,
should by default only modify that repository. If you also have
permissions to modify another repo, it seems reasonable that you have to
tell darcs to do this. I don't like the idea of darcs (by default) going
out and trying to ssh to another computer just to see if you have
permission to run some program named darcs on some other computer, and
whether running that program is successful.
There are many people in the world, and almost all of them aren't me. For
the repositories of any of those people, I can't push --and-apply. True,
if your project is a one-developer project, you might like --and-apply to
be the default, but darcs is designed with multi-user projects in mind, and
in such an environment, --and-apply is unlikely to be helpful. True, there
could be a central user account to which everyone has ssh access, but
that's a unique (and not necesarily common) situation.
I do still think that there should be prefs options on the target
repository indicating what push should do by default. Perhaps something
like _darcs/prefs/apply_if_i_am to indicate the user that would like to
--apply, and something like _darcs/prefs/apply_using_sudo_as to indicate
that users are encouraged to --apply-as. (Yes, I realize those are stupid
names, I just haven't come up with better.) This way one can configure the
default behavior of push on a per-repository basis. So this way
darcs push REPOSITORY
would be interpereted as "Push patches to REPOSITORY using whatever is the
preferred method for that repo, and in any other case, ask me what to do".
> If webdav support was added, then http pushes could also work.
I don't think so. That would also require a "darcs daemon" of some sort
running on the server. Otherwise you'd have to transfer entire files,
which would be wasteful of bandwidth. And writing a server program to go
with darcs seems like a waste of energy (and unnecesary introduction of
potential security holes), when we have the perfectly good email method,
which puts all the potential security holes in the one small piece of code
that verifies the gpg signature (and any code run prior to that, which
> P.S. Does anyone have any comments on my meta-repository suggestion?
Sorry, I've procrastinating responding because I tend to run short on time
in the mornings. Mostly, it seems to be an overly complex solution for a
not-terribly-serious problem. I don't see why any project is likely to
need more than a few branches in a centralized repository, and having a few
copies of the repository doesn't seem like much of a waste.
It seems like one could get most of the benefits with almost no in user
interface by adding a prefs option indicating a local repo to consider
getting patches from via hard link. Then the various commands could try
their best to hard link to patches in that repo when possible, and optimize
could be given a flag telling it to try to change all possible patches to
hard links (possibly even reordering in order to accomplish this). This
has the advantage of not changing the user interface, and not confusing
users who have no need of such a trick by introducing additional commands
and objects. It also has the advantage of allowing me to procrastinate
More information about the darcs-users