[ Greg pauses for a moment, considers, then punts on any deep consideration
or thinking about such a nasty design problem. "later" he thinks... ]
On Wed, Sep 05, 2001 at 11:49:50AM +0200, Sander Striker wrote:
> > From: Bill Tutt [mailto:email@example.com]
> > I'm going to slightly reorder these points to help discussion.
> You forgot to put '3. Ordering' in. [sidenote: if you are going
> to respond to the concept, please reply to the original mail
> with all the points in it]
Why should they all be in there? Maybe he had nothing to say about it.
Trimming down the email is best -- no reason to include the whole mo'fo'
thing just to talk about a few portions of it.
> > Why do there need to be so many privileges? Can't we simplify this to
> > read/write/admin?
> > e.g.:
> > Checkout == Read Access
> > Update == Read Access
> > Rm == Write Access
> > Add == Write Access
> > Mkdir == Write Access
> > Copy(src, target) == Read Access(src), Write Access(target)
> > Move(src, target) == Write Access(src), Write Access(target)
> > Import == Write Access
> > Annotate == Read Access
> > (D)ACL setting == Admin Access
> Annotate is not a read access operation is it?
Sure it is. Why would you think it isn't a readonly operation?
Ah. You're probably thinking "apply annotations". In this case, "annotate"
is used to mean "annotate each line of a source file with who changed it and
when." Look at the "annotate" facility in ViewCVS, or the "blame" concept in
[ note that "cvs annotate" requires read/write access to the repository, as
any other cvs operation does; ViewCVS and cvsblame don't because they
don't bother with locks on the files (a race condition, but screw it :-) ]
> I think splitting out the priviliges in svn terms might be a
> good thing. The [outdated] section in the design doc speaks
> of defining roles which is exactly what good be achieved by
Cover up underlying nastiness with yet more concepts. Bleh.
In practical terms, read, write, and admin are the only things needed.
> I don't think it is that simple. Or I must be misreading it.
> However, this already takes us into the details I tried to avoid in
> the beginning of the discussion. Lets move this to somewhat further
> in the thread when more people have had their say.
If people apply some thought to it and generate a thread :-)
-Greg "Happy with Apache authz for 1.0" Stein
Greg Stein, http://www.lyra.org/
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:40 2006