Live from Tokyo: Tech Blog

CVS Questions

In answer to some questions by Darren Cook I wrote on TokyoPC programming newsgroup the following:

In a fairly large project there are some files I'd like to rename as
the focus of the functions has changed over time. Similarly there is a
directory I'd like to move one level deeper into the tree.

AFAIK if I want to do this I need to cvs remove then cvs add. But if I
do that I lose all the history of changes up until then.

Is there a way around this?

This is a real pain with CVS. If you move something you have to recheck
it in and delete the old copy. The old copy remains "in the attic" so it
is possible to see it's history but the new copy starts a completely new
history. This is a limitation of CVS and apart from some voodoo
techniques like moving and renaming stuff on the server there is no easy
solution. I think Subversion addresses this problem.

On a similar theme I use CVS during development, checking in code that
I later realize is redundant or badly in need of major changes. So I
end with a lot of junk comments in cvs:
Added f()
Bug fix in f()
Radical edit of f() and parameters
Deleted f(): functionality now in f2() and f3().

This looks fine...

With bugfixes I like to just include the Bugzilla number, then someone
can go and look at Bugzilla to see what the problem is.

OK, it can be interesting to see the design trial and error, but IMHO
that is better handled with @internal comments (*).

Unless historical comments are really pertinent to the understanding of
the program or a dire warning to a future developer, they should be
relegated to CVS. After a year or so nobody really wants to know the
history of method or class.

Anyone got any thoughts on this? Should I use a local CVS server and
then add to the main project as a batch (using cvs log on my local
copy to decide what commit message to write)?

The IDEA Java IDE is really cool in that it has in built version control.
You can go back to the source between any compile and diff the versions
locally. CVS is also built in so it is painless to add files and update
files from the IDE. I think it is almost better than WinCVS.

Version control really comes into it's own with a team. It's great to do
an update and get the latest code and see that CVS has merged your
yet-to-be-checked-in changes with some changes that were made to your
file after you started changing it. It's hell though when someone's
changes clash with yours and you have to figure out how to manually
merge the changes. It's then that you wish you had real file checkout
and locking...

My goal is always to be able to produce an release notes file after a
build from the CVS check history for whole project. Something that you
could give to the customer or the testers. Inevitably you have to edit
it a bit but if you write good CVS comments you can keep most of them as
is.

Posted by stuartcw at February 13, 2003 07:27 PM