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

[Zack Brown]

On Tue, Aug 12, 2003 at 10:29:15AM -0400, David Roundy wrote:
> On Mon, Aug 11, 2003 at 10:53:44AM -0700, Zack Brown wrote:
> 
> :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.

$MATCH matches anything following '\/'. So if you're not going to use
it, then you only need:

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

I hadn't realized that the URL and the repodir would be different, but
of course, obviously they are: the URL maps onto the repodir, but is not
necessarily the same. This is a problem because people may not want to keep
all their repos in one directory. darcs is so flexible about allowing any
project to just become a darcs repository wherever it is located on disk,
it's a shame to introduce this constraint.

Isn't there any way for darcs-patcher to determine the repodir at
run-time? Maybe darcs could just keep a config file, containing a running
tab of all repos, and just look up the repodir based on the URL. Any
time darcs runs on a system, then, it would make sure the repo it was
operating on was represented in that file, and if not, would add it. If
the repo moved from one directory to another, darcs could recognize that
the next time it was run, and adjust the config file.

Then the procmail recipe would just be

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

> > > 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...

Ah, I see. So "URL" is a slight misnomer. But maybe allowing something like
"../project" is a security problem, precisely because it could match several
repos.

Can you see any case where a push *should* have that ambiguity? I don't see
any. Yes, it's convenient if you're pushing to a repo on the same machine,
because you don't have to type an absolute path. But it's not that much less
convenient to require a full URL (even just file:/home/zbrown/etc).

> > 
> > 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.

Cool.

Be well,
Zack

> -- 
> David Roundy
> http://www.abridgegame.org
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown