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

David Roundy daveroundy at gmail.com
Wed Dec 12 17:14:15 UTC 2007

On Dec 12, 2007 10:59 AM, zooko <zooko at zooko.com> wrote:
> On Dec 12, 2007, at 4:15 AM, David Roundy wrote:
> > I've written on many occasions, pointing out that I don't think that
> > management of permissions would be a good idea, with the sole
> > exception of the execute bit.  The reason is that in general, each
> > copy of a repository has different requirements for their permissions.
> Do you think that this is analogous to two different repositories
> containing source code having different requirements for the source
> code?

I don't think so, I think that having darcs manage permissions would
be like having it manage file ownership.  We could do that, but file
ownership is meaningless on most other computers.  Similarly the
meaning of "g" and "o" are different on each computer, since the group
is different, and the set of users with access to the computer are

> For example, there might be one repository that requires a certain
> patch or set of patches and another that requires excluding that set,
> even though the two repositories exchange other patches not in that set.
> This is often requested by users on the darcs mailing list, I've
> noticed.

Indeed it has been, and a "patch ignore" file (possibly updated by
darcs itself) is quite reasonable.

> If darcs supported that kind of workflow easily, would such support
> also apply to management of permission bits?

I'm not sure how this would relate.  I suppose you're suggesting that
one could simply never pull changes that affect permissions, thus
isolating those patches, in an attempt to maintain sanity?

The trouble is that darcs should not track permissions at all, in the
normal case, and it gets really ugly trying to come up with a
reasonable semantics that allows people with strange repositories
(e.g. /etc) to track permissions (beyond just the executable bit)
without harming everyone else.


More information about the darcs-devel mailing list