Mark D. Baushke wrote: [snip use-case] > This differers from your case where only a portion > of the repository is restricted. Interesting. Same idea, different subsections (as you say, an inverse of our requirements).
> I would think that the solution to your problem > would be that the commit triggers for your new > co-op code would open the umask for newly added > directories and files to be 000 to allow anyone > access to those files. Hmmm... this might work. This would require whoever adds a directory to also immediately check in a file, because commitinfo will run only when files are checked in. Before permissions are adjusted, if anyone in the other group tries a 'cvs update -d', or anything else that tries to recurse into the new directory, cvs will abort because it can't lock the directory. > If you do feel some kind of trigger on checkout > is needed, you will need to consider: [lots of stuff] Thanks for those points to ponder. Of the 8 add-ons you mentioned, I'm only familiar with two (CVSweb and ViewCVS) - I'll have to familiarize myself with the others (if for no other reason to see if they would be useful for us :-) I'll think on this some more, and if I come up with a more complete proposal I'll post it here for further discussion. -- 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
