[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Milestone 2: authentication and authorization

From: Karl Fogel <kfogel_at_galois.collab.net>
Date: 2000-12-15 01:41:28 CET

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

This is an archived mail posted to the Subversion Dev mailing list.