[darcs-devel] Any answers for IsiSetup's concerns?

David Roundy droundy at darcs.net
Sun Dec 23 13:28:03 UTC 2007

On Sun, Dec 23, 2007 at 12:15:35PM +0000, Ian Lynagh wrote:
> On Thu, Dec 20, 2007 at 07:10:44AM -0500, David Roundy wrote:
> > On Thu, Dec 13, 2007 at 06:53:07PM +0000, Ian Lynagh wrote:
> > 
> > This sounds scary to me.  It looks like it'd have all the problems that
> > setpref has, and I'd rather not repeat that mistake (or at least keep using
> > the same implementation of that mistake).
> The only problems with setpref I can think of are caused by the details
> of its implementation, not anything fundamental.

Yes, the trouble is that we only keep one copy of the prefs, rather than
one pristine copy + one local copy.  I believe that's what you were
proposing to do with this permissions-mapping file.

To quote your earlier email:
> I think we can do this with a layer of indirection. For example,
> "darcs init/get/put" could make a file _darcs/prefs/permissions which
> for me (on Linux with uid=ian, gid=ian) contains something like
>     default ian ian 0600
>     executable ian ian 0700
> On Windows it would probably look different, and perhaps we could also
> support Linux  ACLs, SE Linux, etc. You'd be able to do something like
>     darcs addpermissiongroup executable anotherExecutableGroup
> to make a new line in _darcs/prefs/permissions that would initially be
> a copy of executable (you couldn't just alter it by hand, as then other
> repos wouldn't know which one to copy (unless they defaulted to copying
> default)).

in which you propose to implement yet another patch type that modifies
user-preference data of which we don't keep a pristine copy.  This is
precisely the "details of implementation" that causes setpref to be such a
pain, and precisely why I didn't like your suggesting we repeat this
mistake.  The result is a set of patches that must always trivially
commute, and which manage data that isn't actually managed.  It's

> > I'd say that (if we went with this idea) we should not define this command,
> > but instead use the existing setpref mechanism, perhaps to work like
> > boring, where they can point the permissions at a file of their choice
> > (e.g. one in the repository).
> Which file? The mapping of file to permission class could be a file in
> the repo, but the mapping of permission class to actual permissions is
> per-machine.

No, it *could* be per-machine, but most people probably won't want to
define it, and it *could* be fixed.  And folks can in fact edit the local
copies of files in their repository.

> > > You could then "darcs setpermissions executable myScript; darcs rec".
> > > The permission group for a file would have to be stored under _darcs
> > > somwehere. "darcs rec" could either warn if you change the permissions
> > > with chmod, and it could even try to guess which group you wanted it in.
> > 
> > This is the problem with your approach.  Because we're now storing "extra"
> > information, we are required to implement an extra database.
> That is true, but don't we have plans to do that for other reasons too?
> e.g. a mapping from FilePath to [PatchName], so we know which patches
> affect a file without having to read them all, for optimising "darcs
> changes filename"?

Not that I'm aware of.  I thought the mapping was going to be from
PatchName to [FilePath].  The difference is that this would be done as an
optional optimization, while what you're proposing would be required.

> So for each file we could have a set of extra info, like John was
> suggesting. The easiest way to do this would probably be to mirror the
> repo hierarchy in _darcs/extrastuff (or maybe we would have to have 2
> mirrors, one for file extra stuff and the other for directory extra
> stuff).

I'd still say that since all of this could be done as an external program,
we should wait until someone has already implemented it and shown that it's
useful before we consider adding this bloat to darcs.
David Roundy
Department of Physics
Oregon State University

More information about the darcs-devel mailing list