One point (I'm not sure if this is helpful):
If /main/foo.c and its branch /jimb-branch/foo.c refer to the same
node (3.14), and someone sets a different ACL on one of them, then --
assuming ACLs are implemented as properties -- that means the two can
no longer share the same node revision. But, their non-property
content is still the same, and so that could be shared, or be
expressed with a null text diff, which is very nearly the same as
being directly shared. (And the difference between the property lists
would probably still be small, too).
So when a branch starts having different ACLs than its ancestor line,
some sharing is lost, but not the most important sharing (that of file
contents). Maybe implementing ACLs as properties isn't such a bad
idea after all, then?
-K
Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> Jim Blandy wrote:
>
> > I don't think this works. If I have /main/foo.c referring to 3.14,
> > and then I make a "branch" by copying /main to /jimb-branch, then
> > /jimb-branch/foo.c still refers to 3.14. If ACL's are keyed by node
> > revision number, I can't put a different ACL on /jimb-branch/foo.c
> > than /main/foo.c, because they're identical. In fact, /jimb-branch
> > and /main are the same node revision, too, until I make my first
> > change to /jimb-branch.
> >
> > It's very important to realize that node revision numbers are *not*
> > inode numbers.
>
> Ouch. Of course.
>
> O.K., that leaves two alternatives:
>
> a) Treat an ACL change as a modification, and create a new revision at
> that time. This probably won't work, though, because ACL changes would
> become expensive.
>
> b) Put the ACLs in the directory entries, beside the entry names. This
> would bring us close to how an actual filesystem behaves.
>
> I'd go for b). Opinions?
>
> --
> Brane �ibej
> home: <brane_at_xbc.nu> http://www.xbc.nu/brane/
> work: <branko.cibej_at_hermes.si> http://www.hermes-softlab.com/
> ACM: <brane_at_acm.org> http://www.acm.org/
Received on Sat Oct 21 14:36:17 2006