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

[David Roundy]

On Tue, Aug 12, 2003 at 08:37:42AM -0700, Zack Brown wrote:
> 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

I think that the key is that the URL shouldn't be highly trusted.  The only
time it should be used to tell what the repo is, is if the URL has a unique
directory name in it.  For example, I have a repo called darcs-test, and
have no other directories of that name, so any emails I got for a URL
ending with darcs-test must be for that repo.

If we wanted to do something like this, the thing to do would be to have a
repo advertize its directory (via something like _darcs/prefs/repodir), and
then the email could have a DarcsDirectory: line in it (or something like
that).  Or I've mentioned before a reponame, which could be arranged to be
unique.

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

Yesterday I realized that your idea of using darcs apply rather than
darcs-patcher actually sounds like the way to go.  On further thought,
there seems to be precious little that I want darcs-patcher to do that
wouldn't be useful for darcs apply to be able to do, and it would simplify
the code considerably (not that patcher has complicated code yet...), since
I could leverage all the argument-processing infrastructure that exists for
the darcs program.  In particular, it would make it possible to use the
_darcs/prefs/defaults to set up the apply to have all the arguments you
want (for --cc or --reply or whatever).  I think it'll be much simpler to
make the improvements I want to darcs apply than to darcs-patcher.
-- 
David Roundy
http://www.abridgegame.org