note PotPieMan That's not entirely correct. CVS moves files that you have removed to a directory named <code>Attic</code>. The directory is also under version control, meaning all of the logs are maintained on the old file. You can access the files later using <code>cvs update</code>. First, assume <code>test.pl</code> is at version 1.1. Then, assume the following sequence of commands to rename the file under version control: <code>$ mv test.pl test2.pl $ cvs add test2.pl $ cvs remove test.pl $ cvs commit -m "Renamed test.pl to test2.pl" cvs commit: Examining . Removing test.pl; /home/cvs/personal/projects/music/scripts/test.pl,v <-- test.pl new revision: delete; previous revision: 1.1 done RCS file: /home/cvs/personal/projects/music/scripts/test2.pl,v done Checking in test2.pl; /home/cvs/personal/projects/music/scripts/test2.pl,v <-- test2.pl initial revision: 1.1 done </code> You haven't really removed <code>test.pl</code> from the repository. CVS has stored the file in the <code>Attic</code> directory so that you still have access to it. To access just the log: <code>$ cvs log test.pl RCS file: /home/cvs/personal/projects/music/scripts/Attic/test.pl,v Working file: test.pl head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: ---------------------------- revision 1.2 date: 2003/03/08 04:04:23; author: dwc; state: dead; lines: +0 -0 Renamed test.pl to test2.pl ---------------------------- revision 1.1 date: 2003/03/08 04:03:53; author: dwc; state: Exp; Initial checkin ======================================================================</code> If you want <code>test.pl</code> back, you simply have to issue an update: <code>$ cvs update -r 1.1 -p test.pl > test.pl =================================================================== Checking out test.pl RCS: /home/cvs/personal/projects/music/scripts/Attic/test.pl,v VERS: 1.1 ***************</code> This is a special update that avoids using sticky revision tags. As far as I know, it must be specified to add a file back to the main repository that was previously removed. After recreating <code>test.pl</code> from the previous revision, use the following sequence of commands to add it back to the repository: <code>$ cvs add test.pl $ cvs commit -m "Readded test.pl"</code> I will admit that this is a fairly ugly way of dealing with the problem of renaming files and maintaining the versions on the old file, but saying that CVS throws away the log on the old file is misleading. After adding <code>test.pl</code> back to the main repository, the log file would look as you expect: <code>$ cvs log test.pl RCS file: /home/cvs/personal/projects/music/scripts/test.pl,v Working file: test.pl head: 1.3 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 3; selected revisions: 3 description: ---------------------------- revision 1.3 date: 2003/03/08 03:57:56; author: dwc; state: Exp; lines: +0 -0 Readded test.pl ---------------------------- revision 1.2 date: 2003/03/08 03:55:18; author: dwc; state: dead; lines: +0 -0 Renamed test.pl to test2.pl ---------------------------- revision 1.1 date: 2003/03/08 03:54:05; author: dwc; state: Exp; Initial checkin ======================================================================</code> I would argue that this is safer than editing the RCS admin files. If you make a mistake, all the developers on your team will have problems with the repository. This way, the developers will only see the files being removed or added after you have committed your changes. In general, to make sense of all the different versions in a repository, I prefer to use <a href="http://viewcvs.sourceforge.net/">ViewCVS</a>, a Web interface to CVS repositories similar to <a href="http://www.freebsd.org/projects/cvsweb.html">CVSweb</a>. It gives a very nice interface to the repository, including displaying files in the <code>Attic</code>. Update: Added missing close code tag. --PotPieMan 187449 187636