[darcs-users] suggestion: each push should identify its target repo internally

[David Roundy]

On Mon, Aug 11, 2003 at 10:53:44AM -0700, Zack Brown wrote:
> On Mon, Aug 11, 2003 at 09:53:38AM -0400, David Roundy wrote:
> > On Sun, Aug 10, 2003 at 09:12:25AM -0700, Zack Brown wrote:
> > > Maybe something like:
> > > 
> > > Subject: [PUSH] name of the patch
> > > DarcsRepository: repo name
> > 
> > I've added a
> > 
> > DarcsURL: http://full.path.to/repository
> > 
> > which contains whatever URL you used when doing the push.
> 
> Excellent! So how about this in the procmailrc file:
> 
> :0:
> * ^DarcsURL:\/.*
> | darcs apply --ignore-times -V $HOME/.gnupg/allowed_keys $MATCH
>
> if that works, then creating a pushable repository involves using this
> recipe, installing gnupg, and just adding keys to "allowed_keys". No need
> for darcs-patcher anymore.

Unless your home directory *is* the repository, you'll need to add a cd
repodir to the beginning of that line.

But I would recommend using darcs-patcher anyhow, since this is what it's
designed for.  At the very minimum, you'd want to add
--no-resolve-conflicts to your apply call.  The --ignore-times is also
unnecesary for a pushable repo (assuming you have the
--no-resolve-conflicts), since the local and recorded copies should always
be identical in a pushable repository.

But I believe that using darcs-patcher is a better solution.  Currently it
doesn't do much more than call darcs apply, but makes sure to call it with
the right arguments so you don't have to.  I do plan on adding nice
features like bouncing the email with a "test failed" subject rather than a
"mail delivery failed" subject, and forwarding unauthorized pushes to a
given address.

I've just added support for giving the location of allowed_keys as well as
the repodir to darcs-patcher, so you can use:

:0:
* ^DarcsURL:\/.*
| darcs-patcher ~/path/to/myrepodir ~/the/path/to/myallowed_keys

I also made ~/.gnupg/allowed_keys the default allowed_keys location if a
repodir is specified.

> (BTW I just assumed 'darcs apply' takes the full email of the push from
> standard input. Is that right?  the docs weren't clear...)

Actually, apply won't accept its patch on standard input.  It accepts a
filename for the patch file.  Or is that what $MATCH is? I've never used
$MATCH in procmail.  I don't know if you can give apply the entire email.
It would depend on gpg's behavior.  I've never tried it.

> > This isn't necesarily going to be unique, so I may later add a
> > DarcsRepository line which could be configured.
> 
> I'm not following here. DarcsURL contains a full URL. Isn't there only
> one possible repository that can match that URL?

Actually, that's not necesarily true, since the URL may be a directory
name.  So it could be something like "../project", which could match
several repos... but that would only be if you have the pushable repo
mounted on the same machine on which you have the repo you're pushing
from.  But it still suggests that it might be nice to have have something
like _darcs/prefs/reponame...

> >  Giving a reasonable subject is still on the
> > TODO list.  It's a bit tricky because there could be many patches in the
> > push.  Probably I'll also want to allow the user to specify the subject
> > line, so they could say something like "lots of little bugfixes".
> 
> It would be cool if 'darcs apply' also had -t and -cc arguments, so mailing
> lists and whatnot could be informed when a push was actually accepted. If
> you do this, maybe use the message-id of the push in the references header
> of the new mail, so the acceptance would be in the same thread as the push.
> 
> In that case, the -t and -cc values of the 'apply' will often be very
> similar to the 'push'. The only likely difference would be the fact that
> the person who sent the push would want to receive the reply as well,
> and the person sending the reply won't need to receive it.
> 
> Maybe 'darcs apply' could have a special argument to handle all that at
> once, maybe a '-r' (for reply) could do that address duplication and
> adjustment.

That does sound like a nice idea.  Especially the '-r' idea... the only
catch being that normally apply expects to be given just the patch, so it
wouldn't have the headers.  I should make it accept the whole thing.  That
would also allow you to just use a pipe command from the email program to
do the apply... but then you'd have to specify the directory in which to
apply also.  Hmmm.  I'll think about it.
-- 
David Roundy
http://www.abridgegame.org