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

RE: Authorization [2]

From: Sander Striker <striker_at_apache.org>
Date: 2001-09-05 14:19:20 CEST

> [ 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:billtut@microsoft.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.

Right. My bad. The sidenote was there for future replies so that
other points would not be forgotten.

>>> Why do there need to be so many privileges? Can't we simplify this to
>>> read/write/admin?

>> 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 Bonsai.

Ah. Confusing term "annotate".
>> 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 could be achieved by
> Cover up underlying nastiness with yet more concepts. Bleh.

That is the downside ofcourse.

> In practical terms, read, write, and admin are the only things needed.

I'm sceptical about this being fine grained enough. Ofcourse,
we'll just have to see if it is [it could very well be].
>> 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 :-)


> Cheers,
> -Greg "Happy with Apache authz for 1.0" Stein

Oh, I am also perfectly happy with apache authz for 1.0, I just
want to make sure the 1.0 code leaves enough room for complicated
authz to be added [I currently think it does].


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:40 2006

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.