Todd Denniston wrote: > ok another set of assumptions on my part > 1) each _project_ has a separate repo and any NDA stuff is kept even > separate from the other normal things. Hmmm... given the large number of projects we have, which share sub-projects (e.g. internal libraries) this wouldn't be practical for us.
> 2) you have three sets of users, a) ones who can write to the > repo, b) those > who can read from the repo, and c) those who have no rights > to the repo. > This is all I have had to deal with. Ah, the simple life ;=) > If I had to have a section where all my staff could > read/write a section of > the repo and co-ops could read/write that section as well, I > would probably > make group staff a member of group coops, and set that > section of the repo to group coops. Well, according to our sysadmin, a group can only have users as members - a group cannot contain another group. That seems like a major shortcoming to me, but that's what I'm told. > 3) if I don't want someone having checkout privs then they > are not in the > group for that project or the group that has write privs to > the LockDir. > Note: each project in my world has its OWN group, being in > group staff gets > you VERY little. I had suggested one group per project, but that has its own set of difficulties: - Each user has a default group that is used to set permissions on new files (I know there's supposed to be a way to configure the O/S to inherit permissions from the parent, but our sysadmin either hasn't figured it out or is too busy to correct the problem). - Each full-time user would now have to be made a member of each project group - quite a manually-intensive, error-prone chore. > Sorry, > I lead a sheltered life with an un-interesting mix of users. :) Well, "interesting" is a two-edged sword :=) Your approach is certainly useful for a less complex organization than ours. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
