RE: refactoring when using CVS

[Glew, Andy]

I've been practicing XP, to a greater or lesser degree,
for 4 years using C/C++ and CVS.

Yes, XP with CVS can be done.

Yes, CVS makes renaming files a pain. You inevitably corrupt
history, whether you cvs remove oldname / cvs add newname
(losing history) or whether you copy the ,v file in the archive
file (creating false history).
        My current BKM (Best Known Method) is to create
and version control a BOM file, a Bill-Of-Materials listing all
files in a project.  I then "make BOM-clean" to remove any files
that don't belong to a particular version.  This allows the copied
,v files to not pollute the source code in my workspace, although
they do pollute in my CVS repository.  I don't remove or rename
tags in the copied ,v file.

Yes, support for renaming files should be added to some hopefully
soon CVS successor.  I think that it could be added fairly easily to
CVS via a level of indirection: always use a filemap to find files
that have been renamed.  I think Noel's comments about locking
are probably paranoid: for common cases, such as renaming within 
the same directory, not a problem.

However, I think the concentration on file based renaming may be
too narrow-minded.  Refactoring intensive approaches like XP 
do a lot of "move method" refactorings -- moving a method from one
class to another.  If you do this inb a world where all routines for
a class tend to live in the same .cc/.hh files (or whatever your suffixes
are), this means that code for the routine is moving from one file
to another.  If you want to diff against old versions of the routine,
across move-method refactorings, file renaming doesn't help.
        Sometimes I think that the old Cray style "Deck Of Cards"
version control systems are better than UNIX-style file versioning systems,
because they allow a line of code to be tracked from class to class.
IBM Visual Age for Java appears to be able to do this.