[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: starting over

From: Mark E. Hamilton
Subject: Re: starting over
Date: Wed, 30 Aug 2006 11:57:33 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12) Gecko/20050920


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]