I know. I know. But we making these changes before getting all of our code under version control would have been, imho, putting the cart before the horse.
On 7/25/05, Todd Denniston <[EMAIL PROTECTED]> wrote: > Rondal Ellifritt wrote: > > > > Got it. I didn't pick up the nuance of the order of precedence of > > those three things when I read your message the first time. So, the > > problem is that we're all using the same working directory which, of > > course, has the same CVS/Root file and the author label is being > > picked up from that. But we can override that by using the -d option > > on the command line. > > > > Right? > > > > I am not sure you can override the user name by using -d, but you could try > it and find out in a safe place. :) > > Easiest method though for getting their name on the commit if that does not > work ... type the users name as the first line of the commit comment. :) > > A related email thread is [2]. > > However it sounds like IIRC the last set of our messages, that your next few > steps are: > 1) get the scripts so they can be executed from arbitrary locations, i.e., > developers can run the scripts from their own directories and not affect the > installed set (and production logs). Last time you indicated they are > currently constructed so they only work from and on a fixed set of > locations. > > 2) get the developers to start working in their own sandboxes (step 11 from > our last discussion). This means NO ONE works in the production area > anymore. > > 3) investigate your options on either having a human decide when the new > script code is production ready, or look at "Keeping a checked out copy"[1] > in the manual. Then use this new procedure to keep the production area up to > date. > > 4) change your password so the developers have to start using their own > passwords and user names. > > > Good luck. > > [1] https://www.cvshome.org/docs/manual/cvs-1.11.20/cvs_18.html#SEC177 > A related email thread: > http://lists.gnu.org/archive/html/info-cvs/2002-10/msg00463.html > > [2] http://lists.gnu.org/archive/html/info-cvs/2002-06/msg00047.html > > > > On 7/23/05, Larry Jones <[EMAIL PROTECTED]> wrote: > > > Rondal Ellifritt writes: > > > > > > > > Thanks, Larry. I may well be suffering from many misconceptions, > > > > common or otherwise, but that one doesn't explain my problem. We are, > > > > in fact, all using different CVSROOT variables. (We get to the unix > > > > environment using Exceed from a Windows environment, and we set a MYID > > > > variable as part of the Exceed login script. We then use that in > > > > .cshrc to set CVSROOT properly.) > > > > > > Please read what I wrote again carefully. Setting the $CVSROOT > > > environment variable has no effect when you're in an existing working > > > directory: > > > > > > > > The CVSROOT for a particular > > > > > directory is the one specified by the global -d option on the command > > > > > line, if any; failing that, it's the one recorded in the CVS/Root > > > > > file, > > > > > if any; or, as a last resort, the one specified by the $CVSROOT > > > > > environment variable. > > > > > > > > > > If you're all using the same Unix login, you're probably all using the > > > > > same working directory, which means it's going to be inconvenient to > > > > > get > > > > > things to work the way you want -- you'll have to always specify > > > > > CVSROOT > > > > > on the command line. > > -- > Todd Denniston > Crane Division, Naval Surface Warfare Center (NSWC Crane) > Harnessing the Power of Technology for the Warfighter > _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
