Move a file in CVS without resetting the revision number.

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

The generally accepted way to achieve this effect is to perform the following steps. The technical term for this is a repocopy.

1. 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.
2. On the client side cvs delete the file from the old location.
3. On the client side cvs update the directory contents in the new location (so that the file will appear there).
4. 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.

Answer 6

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.