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

Zack Brown zbrown at tumblerings.org
Wed Aug 13 14:46:05 UTC 2003


On Wed, Aug 13, 2003 at 09:35:16AM -0400, David Roundy wrote:
> On Tue, Aug 12, 2003 at 08:37:42AM -0700, Zack Brown wrote:
> > 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.
...
> 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.

this seems like an arbitrary restriction - people shouldn't have to
remember not to use a directory name they've used elsewhere before.
Repos are likely to get sprinkled all over the disk over long periods of
time, and the chance of violating that rule will just grow and grow -
especially because some reponames (like 'test') really suggest
themselves for certain purposes, but would be restricted under that
design.

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

OK, try this on for size:

there are two possibilities. A URL or a path. If it's a URL, there's no need
for any other information. Just parse the apache config files, and you're
done. they will point you to the proper directory.

If it's *not* a URL, but just a full path or a relative path, then darcs
should reject any push that doesn't originate with the same user that's
receiving it. If I'm pushing something to myself, I can assume that I
trust myself; but anyone else pushing something to me, almost certainly
won't have intimate knowledge of my directory structure, and so they
should use the public URL.

This solution allows darcs to rely only on the DarcsURL header, allows users
to create repos with any directory name, and makes sure darcs finds the right
repo in a trusted way. The only thing you lose is the ability for arbitrary
users to specify path names on your personal system. No big loss, IMO.

...

Something else just occurred to me. The user may want to allow certain
people to access one repository but not another. Specifying a single
allowed_keys file in the procmail recipe doesn't allow that. I think
procmail could be wrestled into dealing with this, but I think there's a
better solution:

Why not put the allowed_keys in the _darcs/ directory of each pushable
repository? Then you won't even have to specify the key list: darcs will just
know, and there will be different groups of allowed users per repository. So
(along with the idea of using 'darcs apply' instead of darcs-patcher),
the procmail recipe will no look something like this:

:0:
* ^DarcsURL:
| darcs apply -r

Can't get much simpler than that...

Be well,
Zack

> 
> > > > 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.
>
> 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
> 
> _______________________________________________
> darcs-users mailing list
> darcs-users at abridgegame.org
> http://www.abridgegame.org/mailman/listinfo/darcs-users

-- 
Zack Brown




More information about the darcs-users mailing list