Re: Using CVS for revision control

[Abigail-II]

Just a few things.

You are claiming CVS is the most widely installed and used revision control system in the GNU world. This may be true, but do you have anything to back up your claim?

There isn't a need to add a CVSROOT to your environment variables permanently. It's only need if you either initially checkin a source tree (using "cvs import"), create a repository ("cvs init") or do the first checkout of a project ("cvs checkout"). But for normal day to day actions ("cvs add", "cvs commit", etc), the repository is retrieved from the CVS admin files.

You also say a file cannot be removed from CVS, but I thought that's what "cvs remove" is for.

There is one action that's lacking in the CVS command set. You cannot rename a file other than manually modifying the repository and the admin files. This is troublesome if many developers have checked out the module.

Abigail

[Tomte]

There is one action that's lacking in the CVS command set. You cannot rename a file other than manually modifying the repository and the admin files. This is troublesome if many developers have checked out the module.

You're right, there is no way of renaming a file while keeping track of this change in cvs, but instead of manually messing around with the administration files, you (AFAIK) would (in your working dir):

• $> mv myfile ~/backups
• $> cvs remove myfile
• $> cvs commit myfile
• $> mv ~/backups/myfile newname
• $> cvs add newname
• $> cvs commit newname

This is one of the few ugly parts of CVS; but while your starting to use it, you may give meta-cvs a try. I did not, because of my high workload there's no time for such improvements :-(, but it seems to be worth a try.

regards,
tomte

[Abigail-II]

That will make it impossible to retrieve older versions of the file, and your CVS log will be erased.

That's why I prefer to modify the admin files by hand.

Abigail

[PotPieMan]

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:

$ 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

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:

$ 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
======================================================================

If you want test.pl back, you simply have to issue an update:

$ 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
***************

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:

$ cvs add test.pl
$ cvs commit -m "Readded test.pl"

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:

$ 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
======================================================================

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.

--PotPieMan

[Tomte]

That will make it impossible to retrieve older versions of the file, and your CVS log will be erased.

I called it therefore ugly...

That's why I prefer to modify the admin files by hand.

But you wouldn't recommend this to a CVS newbie, would you?


regards,
tomte

---