Lieven Govaerts wrote:
>> -----Original Message-----
>> From: Greg Thomas [mailto:firstname.lastname@example.org]
>> This makes it impossible to give anonymous read only access, a very
>> desirable feature:
> That's not correct!
> First of all, in your example Subversion will behave like this:
> 1. if you need read access: the first line applies, so it grants you
> read access
> 2. if you need write access: it skips the first line, and grants you
> access based on the second line of you're in the developer group.
Greg's comment was in response to the suggestion that subversion should
use the most restrictive set of permissions, as opposed to its current
system of using the most open.
You're right that, as currently coded, if someone needs write access,
subversion looks to see if there is any permission line granting it
(such as the @developers = rw line in Greg's comment). However, if
subversion went with simply the most restrictive, then it would, as Greg
suggested, examine both lines, note that the user qualifies under both,
and take the one that only gives read access.
Frank suggested that subversion should, perhaps, use the last permission
line the user qualified for; thus, in this example, it would look at the
first line, which gives the user read-only access, and then the second,
and if the user were a developer, they'd have read & write access.
In other words:
would grant global read, and read-write to developers;
would initially grant read-write to developers, but then revoke write
priveleges from everyone while granting read; and
would grant everyone read access, read-write to developers, and then
revoke all priveleges from joe. Under subversion's current system, I
believe that all three examples would give global read access, and
read-write to developers. Jeb's suggestion (that the most restrictive
permissions should apply) would give read-only access to everyone, and
read-write to no one in all three examples; in the third, it would also
remove joe's read priveleges.
Personally, I like Frank's suggestion best, as it gives the most
flexibility in terms of controlling who has access, and seems to be the
most intuitive way to read the control files.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Fri May 19 17:36:33 2006