[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: starting over
Mark E. Hamilton
Re: starting over
Wed, 30 Aug 2006 11:57:33 -0600
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
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
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.