tardate 2024

my recent reads..

Migrating to a Virtual CVS Host

Dec 26, 2007 SCM Perl cvs
4 minute read
Seasons greetings to all! Of course, a few days off means time for some of those special projects that have been waiting in the wings;-)

I run a cvs repository for my personal use at home (migrating to subversion is a project for another xmas break). There are two stupid mistakes in the setup I've wanted to fix for a long time.
  1. It is running on the main machine I use for testing and development, which can lead to some tricky catch-22 situations. Duh!
  2. I've always used the servername to access the repository, which makes relocation a pain. This seems to be a problem common to the many development shops I have seen. Gold stars for actually using source control, but brickbats for not thinking of using a virtual host name before finding yourselves tied to a specific host!

The Relocation


Actually, by moving to a new server I mean old laptop .. it is easy to write-off a 256Mb 600MHz machine these days, but they really do make decent "network utility" servers! Running Linux of course. Ideal for just sitting in the corner and running your crucial network services day in, day out. Like cvs.

Since I was migrating the cvs repository from another Linux machine, the move was a piece of cake. The following notes assume Red Hat (or Oracle Linux), which is what I am running. It also assumes the cvs repository is at /cvsroot and the cvs user account is called cvs (just substitute your actual details where approriate).

CVS Setup - New Server
Most Linux distributions will already have the cvs server installed (but not configured or running). Since I'm on Red Hat, I can check for the cvs package using rpm:
$ rpm -qa | grep cvs
cvs-1.11.2-27

If you can't find the server package, download and install as appropirate for your distro.

Setting up the CVS Service
Create a new cvs user and group to own the repository.
[root@new server]# /usr/sbin/groupadd cvs
[root@new server]# /usr/sbin/useradd -g cvs cvs
[root@new server]# passwd cvs

Check that the service name is listed in /etc/services
$ grep cvspserver /etc/services
cvspserver 2401/tcp #cvs pserver process

To get the cvs server under xinetd control, create /etc/xinetd.d/cvspserver:
service cvspserver
{
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
server_args = --allow-root=/cvsroot -f pserver
}


Move the Repository Files
Normally at this point you would initialise a new repository if you are setting up a server from scratch (cvs -d /cvsroot init). However in this case I'm moving the repository files from the old to the new server. For me, this meant tar/gzip of the /cvsroot, ftp the archive to the new machine, and unzip to re-create /cvsroot.
[root@old server]# tar -zcvf cvsroot.tar.gz /cvsroot
[root@new server]# cd /
[root@new server]# ftp {file from old server}
[root@new server]# tar -zxvf cvsroot.tar.gz


Starting the Server
[root@new server]# /etc/init.d/xinetd restart
Voila!

Switching to a Virtual Hostname


OK, now we get to the main point of the post - using cvs with a "virtual hostname". I mean of course using a name that belongs to the cvs service rather than any particular server, which will make future relocations to new servers a breeze if it becomes necessary.

So where I used to access "server1.mydomain.com", I will now use "cvs.mydomain.com". These names can be resolved by DNS or hosts file. They could actually map to different IPs (i.e. use virtual IP address also), but in my case I have just setup "cvs.mydomain.com" as an alias for my new server's IP address.

To preconfigure the cvs environment for Linux users I add the following to /etc/profile:
export EDITOR=/bin/vi
export CVSROOT=:pserver:$USER@cvs.mydomain.com:/cvsroot


Migrating CVS Clients
Now what about all the cvs "clients"? Strict protocol would suggest you should make sure everything is checked in before the server move, and check out a fresh copy from the new server when it is ready. This is not really a nice way to go for at least two reasons:
  1. You'll probably miss something that needs checking in
  2. If you have directories with a mix of cvs controlled/non-controlled files you have an interesting mix-and-match problem to get everything back in sync
Fortunately there are some tricks you can employ to do an "in-place" migration of modules checked out on the client. Basically we just need to update the CVS/Root files with the details of the new server.

Here's a quick perl recipe for updating all of the CVS/Root files under the current directory in Linux:
perl -i.orig -pe "s/myacct\@server1.mydomain.com/mynewacct\@cvs.mydomain.com/g;" $(find . -name Root)

On Windows, you can use the extended FOR syntax to descend the directory tree:
for /R %r in (Root?) do perl -i.orig -pe "s/myacct\@server1.mydomain.com/mynewacct\@cvs.mydomain.com/g;" %r

These perl one-liners (-e) loop line-by-line (-p) through the file, modifying it in-place while also creating a backup file with the .orig suffix (-i.orig). Each line of the file is evaluated with the global search and replace regular expression (s///g).