[EMAIL PROTECTED] on 2000.02.23 23:29:35
>[ On Monday, February 21, 2000 at 09:39:31 (-0500), Noel L Yap wrote: ]
>> Subject: Re: removing the need for "cvs add file" to contact the server....
>>
>> > Given the current design of CVS there can be *NO* reasonable argument
>> > for creating empty directories in the repository and leaving them there.
>>
>> Yes there is. Let me lay it out again (and remember, you helped come up with
>> this even though now you want it null and void):
>> 1. A cvs admin has the responsibility of being the only person to create
>> directories in the repo (ie add directories and import modules). Rationale:
The
>> cvs admin must be able to have fine-grained control over permissions within
the
>> repository. Since only the file/directory owner can change permissions on
that
>> file/directory, the cvs admin must own all directories in the repo. Since
>> directories are owned by those that add the directories, only the cvs admin
must
>> be allowed to create directories.
>> 2. After the cvs admin has created the empty directory, other users will
>> checkout the empty directory, then add whatever files they wish.
>
>You are using CVS as it stands incorrectly and as such your argument
>about needing to create empty directories in the repository is invalid.
>Please read the manual and follow the directions it gives in order to
>achieve the available and possible forms of access control.
Greg, we've gone through this several times. The manual doesn't mention ACL's
at all. Does this mean that they shouldn't be used? Should I also not use
emacs 'cos the manual doesn't mention it?
CVS doesn't manage permissions. This is fine. What's not fine is that you say
that it prohibits me from managing those permissions.
Perhaps the problem is that you've never used (nor have ever needed or wanted to
use) ACL's. On top of that, you have this mindset that your environment
reflects everyone else's environment.
>> No, I completely understand how CVS manages permissions (ie it doesn't). All
>> CVS does is use the permissions afforded by the file system. Since I need
>> finer-grained control over permissions than you do, you claim that this need
is
>> false. Greg, the world is a lot larger than your weird.com world. Version
>> control (eg CVS) and access control (eg ACLs) are orthogonal issues. CVS
>> shouldn't force me to have a root script running that'll change ownerships of
>> directories in the repo.
>
>Whether or not you need finer grained control over permissions is
>irrelevant to this point. Just because your specific needs seem to
>indicate to you that some extraordinary changes be made in the way CVS
>deals with access authorisation doesn't mean that the result is suitable
>for the general case and thus suitable for re-integration into a
>commonly used version of CVS.
Nowhere have I ever said that CVS must be changed to meet my needs. It works
now (although you claim that this is a bug). Even if "cvs add dir" was replaced
by "cvs add dir; cvs ci dir", the procedure I've outlined will still work so
long as dir is added into the repo whether or not it's hierarchy is empty.
>Indeed version control and access control are orthogonal, *except* where
>they intersect.
Duh, this is a tautology.
> I have in fact separately outlined several ways that
>you can do what you want without having to do things the way you seem to
>think you have to do them.
Yes, most require root access.
>A repository maintenance program run as a
>privileged user is only one of those alternatives. A proper risk
>assessment and perhaps better definition of your access control
>requirements might also simplify things to the point where excessively
>paranoid schemes are not necessary and the documented scheme will be
>more than adequate.
We've gone over this, too. Such SS tactics won't work in our environment.
Furthermore, these solutions don't solve the original problem of *managing*
permissions within the repo.
Noel
