|Pathologically Eclectic Rubbish Lister|
Re: Using CVS for revision controlby PotPieMan (Hermit)
|on Mar 08, 2003 at 04:20 UTC||Need Help??|
That's not entirely correct.
CVS moves files that you have removed to a directory named Attic. 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 cvs update. First, assume test.pl is at version 1.1. Then, assume the following sequence of commands to rename the file under version control:
You haven't really removed test.pl from the repository. CVS has stored the file in the Attic directory so that you still have access to it. To access just the log:
If you want test.pl back, you simply have to issue an update:
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 test.pl from the previous revision, use the following sequence of commands to add it back to the repository:
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 test.pl back to the main repository, the log file would look as you expect:
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 ViewCVS, a Web interface to CVS repositories similar to CVSweb. It gives a very nice interface to the repository, including displaying files in the Attic.
Update: Added missing close code tag.