Re: Problem with Author Label

[Todd Denniston]

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