Re: Problem with Author Label

[Rondal Ellifritt]

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 <address@hidden> 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 <address@hidden> 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
>