As far as CVSROOT goes, CVS uses the first available defined CVSROOT of the following three ways to get it:
- the -d option to cvs command - the CVS/Root file in a workarea - lastly, the CVSROOT env variable This is what you want to do: 1) create an anonymous readonly CVS account. 2) create the shared workarea logged into CVS with that account. This will, by default, prevent commits by the user that created the workarea. -- identifying yourself to CVS 3) If developers will share an OS account, then each deveopler will need to setup cvs to use 'cvs -d <CVSROOT>' with their own id in places of 'cvs' when in the workarea. They can alias cvs on UNIX or use the .cvsrc config file. -- being able to write to the workarea 4 <optional>) IF developers use there own OS account in the common workarea, they will (in addition to the above) have to be in a common OS group and set the CVS_UMASK variable to allow write access to that group. Mark --- Judy Pearson <[EMAIL PROTECTED]> wrote: > > Unix cvs server (cvs 1.11.1p1) with the pserver access method > Unix (cvs 1.11.1p1) and WinCVS 1.2 clients. > > > Our shop is in the process of moving from VSS to cvs (yay!). I have a set of > Java/jsp programmers who share development in one > working directory. (They will not be convinced that sharing a directory isn't > a good idea.) > > In VSS, these developers are able to lock/edit individual files in the shared > directory and have their names associated with the > edit/commit/etc. > > In cvs, the CVS/Root file is blocking a similar type of programmer/file > access. The name of whoever checked out the module is saved > in CVS/Root and used for subsequent cvs operations on the directory. I have > seen that removing the Root file causes the $CVSROOT > environment variable to be used. If there are no negative side-effects of > removing CVS/Root from these common work areas, it would > allow the developers to distinguish themselves in their file access. (I know > we'd have some annoying write permissions problems to > get around, but that's not a big concern to the developers.) > > Assuming $CVSROOT is set properly, what is the effect of removing the > CVS/Root file from a working directory? > > I do not anticipate any of these development efforts using two different > repositories, so we would not face the bother of needing to > have the CVSROOT change from one directory to another. > > I haven't seen any negative effects of this in my testing, but I also have > not been successful at finding information on this in web > searches. I looked through the source code and it looks like this should work > fine. There is actually a comment in root.c stating > that > * It is possible that not all repositories will have a CVS/Root > * file. This is ok, but the user will need to specify -d > * /path/name or have the environment variable CVSROOT set in > * order to continue. */ > > > Of course, any recommendations of other ways to address this issue are > welcome. > > Thanks in advance for your time. > > - Judy > > > > _______________________________________________ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
