Re: Problem with Author Label

[Todd Denniston]

Rondal Ellifritt wrote:
> 
> 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.
> 

Agreed.

But as I understand it, now you have the code under VC, so now it is time to
assign someone[1] to begin the effort of making the the system more
reusable/portable, and as quickly as possible. Note the order I have things,
you continue with the current setup (everyone pretending to be you) until
the code has been modularized. Making the code more modular is a difficult
task at first but it is something that is very important for the future,
even if you have only a single developer and a single client. Modular code
is a lot easier to maintain and configure, at least from my experience. If
much development is going on currently with them, it might be a good thing
to put the team doing the modularization on a branch (or put everyone else
on the branch) so that both efforts can be done quickly.

My experience:
I have 26 scripts which are used to maintain my (and other groups)
repositories, when I got them they all had to be configured individually for
each new project (repository) and were not consistent in their use over the
whole set. When I recived them in 1999 it took 3 to 5 days to get them all
configured correctly and reasonably consistently (from my rcs records of the
time) because you had to edit them all, now in 2005 it takes less than an
hour (after doing a cvs checkout of them) and only 3 files have to be edited
(two if you want to leave a record file in it's default location, I may move
that to the main config file shortly) and all the scripts work consistently
against the configured repository.

[1] actually probably the whole dev team, really it should be a reasonably
quick thing to do if you have a senior person design how to do it and then
have someone assign sub tasks to get the design implemented.

> 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
> >
> >
<SNIP>
-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) 
Harnessing the Power of Technology for the Warfighter