Lately I've be moving source files around in our source tree. For example placing a bunch of files into a common assembly. I've been doing this my deleting the file from CVS and then adding it again in the new spot. The problem is the revision number of the file resets back to 1.1. Is there some simple way to move things without having the number reset.
I probably should have mentioned that I don't have access to the repository so anything that requires that doesn't help me but it might help others.
There is no way to move files around with client-only commands. You need access to the servers file system and can move the ",v" file in the repository to a new location. This will keep all history, since CVS records every revision and their comments in that one file.
Keep in mind that files are moved into an "Attic" subfolder (which cannot be seen from the client) when they are deleted. This is how files can be restored after they have been deleted.
Generally there are no immediate problems with this approach, however you have to consider the consequences should you decide to check out an earlier version of your product which might rely on the previous directory structure!
This is where other revision control systems like Subversion have a definitive advantage.
The generally accepted way to achieve this effect is to perform the following steps. The technical term for this is a repocopy.
- Login on the server hosting the CVS repository and copy (don't move) the repository file from the location you want it to the new location.
- On the client side cvs delete the file from the old location.
- On the client side cvs update the directory contents in the new location (so that the file will appear there).
- On the client side perform a forced cvs commit (using the -f flag) of the copied file to log the fact that it was repocopied (add a log comment to that effect).
This procedure maintains the file history in its new location, and also doesn't break the backward continuity of the repository. If you move back in time, the file will correctly appear in its old location. You can also use the same procedure to rename a file.
The online CVS manual has some detail on how to do this:
The normal way to move a file is to issue a cvs rename command.
$ cvs rename old new
$ cvs commit -m "Renamed old to new"
This is the simplest way to move a file. It is not error prone, and it preserves the history of what was done. CVSNT clients can retrieve the original name by checking out an older version of the repository.
This feature is only supported on CVSNT servers 2.0.55 and later.
well the simplest way would be to acess the cvs server where your repo is and just move your folders/files around with mv (assuming a *nix machine). that way the history of the file will be keeped.
Isn't this one of the known flaws with CVS - no inbuilt mechanism for moving files? It has been a long time since I used it however, so maybe there is now a solution.
Subversion will allow you to move files, but that will be tracked as well so the new file gets the most recent revision number.
It seems to keep the version history you haver to use the -v option when moving see below
CVS renaming of files is cumbersome.
To the repository point of view, you
just can delete files or add new ones.
So, the usual process is
mv oldfile.c newfile.c cvs delete
oldfile.c cvs add newfile.c
This does work, but you lose all the
change information you care to wrote
in commit operations during years of
hard development and that is probably
not what you want. But there is a way;
you must have direct access to the
repository. First, go there, find the
directory where your project is and do
the following:
cp oldfile.c,v newfile.c,v
now go to your working directory and
do a cvs update ; newfile.c will
appear as a new file. Now you can cvs
delete oldfile.c and commit.