Jim Blandy <jimb@zwingli.cygnus.com> writes:
> > 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?
>
> Don't you want to be able to change the access allowed to old
> revisions?
I was going to ask
"Does it make sense to allow access to certain content if reached
via one rev:path, while denying it if reached via a different
rev:path?"
when I realized that yes, it does make sense. The association of the
rev:path with the content is, itself, a possibly sensitive piece of
information.
So back to square one. How nice it feels to understand the issue now,
though, I must say. :-)
Received on Sat Oct 21 14:36:17 2006