Re: starting over

[Mark E. Hamilton]

Robert,

Huber, Robert wrote:
> Dubious in this case basically means that CVS has not been used by the
> various developers on the project consequently there is no confidence in
> the contents of the repository and the concern is that a developer may
> get a copy of old code. The code in the production area is what is used
> to make changes; a personal copy is made, modified, tested and basically
> put back in production.

Well, the first thing that you must address is your management problem. 
As section 1.2 of the CVS manual states: "CVS is not a substitute for 
management." If you have developers not committing changes to the 
repository and directly updating the production area there's no way you 
can guarantee that your production area is correct.

Lets suppose, for instance, that both developer A and B take a copy of 
production at the same time. Both make changes and test them 
successfully. Developer A then copies his changes into production;. 
Sometime after that developer B copies his changes into production. If B 
copies all of his files into production this will delete *all* changes 
made by A. If B only copies the files he changed then only some of the 
changes made by A might be deleted (if they both worked on the same files.)

If B deletes all of developer A's changes it's not so bad (except from 
A's perspective) since production will still work. However, if only part 
of A's changes were overwritten then your production area is now 
corrupted and non-functional, even though B's changes worked as tested. 
The situation you are in now is a recipe for disaster, and it's exactly 
this sort of situation that CVS is designed to prevent.

The first thing that you must do is document a development model for how 
your developers should work; how to check out current code, how to 
change and test it, how to commit it, and how and when to update the 
production area. (If you involve the developers in this you'll have less 
resistance later on.)  I'm sure there are some good books on this, but 
I'm not that familiar with them. Perhaps someone else here can recommend 
some. You also need to get management buy-in for your model, since they 
will be the big-stick when it comes to enforcing it.

You also need to select a branching model for your repository. Where I 
work we use the model where development is done on the head of the 
default branch, with regular branches made off of this branch for 
releases. Only bug fixes are then allowed on the release branches. This 
works fairly well for us, but there are other approaches. Some never 
branch at all but simply tag release points (which might work well for 
you,) others allow multiple development branches and merge them together 
for releases.

Next you need to educate your developers on the model and how to use 
CVS. The Cederqvist should be your first resource for this. "Pragmatic 
Version Control using CVS" and "Essential CVS" are two other books that 
could help with this. There's also a lot of online resources that Google 
will turn up.

Now we come to the repository. It's useful to remember that a server can 
host multiple repositories. A repository is just a directory that 
contains a CVSROOT directory with all the CVS admin files, and zero or 
more top-level project directories.

You could simply initialize a new repository elsewhere (for instance 
:method:server:/usr/local/our_repos), import your current production 
area into that repository, read/write protect the old repository, and 
tell the developers to start using the new repository. This is the 
simplest approach, but none of the file modification history will be 
available in the new repository. (Ie, developers won't be able to check 
out versions of foo.c prior to the switch to the new repository.)

Though it may be harder, my approach would be to get the current 
production code into the existing repository. This preserves all 
historical information in one repository.

Since your production area is presumed correct what you could do is to 
check out the head of the default branch of your project(s) into a 
working directory somewhere. Then copy all the files from the production 
area into your working directory. (If the production area contains CVS 
sub-directories you need to ensure that they are *not* copied into your 
working directory.)

Check for directories and files that need to be added and add them with 
'cvs add' (directories first.) Removed files are a little harder as they 
will exist in your working directory but will not exist in your 
production area. You should be able to use 'diff -r' to identify files 
that only exist in your working directory. Use 'cvs remove' to remove files.

At this point you should do whatever testing is required to ensure that 
your working directory accurately reflects your production area and 
works correctly. Assuming that passes you should be able to do a 'cvs 
commit' and the project(s) in your repository should be correct.

Finally, you should implement whatever development model and branching 
policy you've chosen at this point. If you can't trust your developers 
you may want to write-protect your production area, limiting changes to 
it to only a trusted user whose job it is to update it when required. 
Our production area here is actually checked out from the production 
branch, which makes updating it after bug fixes simple. Using cvs export 
to create a production area from a branch may be better for some 
systems, however, because it excludes the CVS sub-directories.

--
----------------
Mark E. Hamilton
Orion International Technologies, Inc.
Sandia National Laboratory, NM.
505-844-7666