[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: moving a CVS repository to a newer/faster Linux box

From: Riedel, Brian
Subject: RE: moving a CVS repository to a newer/faster Linux box
Date: Fri, 18 Nov 2005 15:38:54 -0600

Any ideas?  I installed cvs and I am doing an initial test to see if I
can connect to the repository.

$ cvs -d :pserver:cvs@<box>:/development/cvsroot login
Logging in to :pserver:cvs@<box>:2401/development/cvsroot
CVS password:
cvs [login aborted]: connect to <box>(<boxid>):2401 failed: Connection

Connection refused?  Any ideas?

-----Original Message-----
From: address@hidden [mailto:address@hidden
On Behalf Of Todd Denniston
Sent: Thursday, November 17, 2005 9:02 AM
To: Mark E. Hamilton
Cc: Riedel, Brian; address@hidden
Subject: Re: moving a CVS repository to a newer/faster Linux box

"Mark E. Hamilton" wrote:

Mark's suggestions are good, but I want to put a couple of suggestions

> Riedel, Brian wrote:
> > We are in the process of moving a CVS repository off the current 
> > Linux box to a newer/faster Linux box.  I have been searching your 
> > site for instructions, and I am looking for instructions for setting

> > up the new box (instructions to the sys admins), as well as best 
> > practices in moving/importing the modules to the new box.  I assume 
> > importing is the best method.
> Search the archives a little more, you'll find it.
> Importing is not the best method if you are simply moving to a 
> newer/faster server. You'll lose your history that way.
> What I've done in the past is:

0.  It is less error prone to first have everyone do a final commit to
the current machine, and remove their sandboxes, than to use a script
changing CVS/Root files.

0.5  setup a "CNAME" (?? essentially an alias to the real DNS name) in
DNS called something like, so that as long as
everyone is using remote access to the server, you might be able to skip
0 and 5 on future moves.

> 1. Manually add 'ALL false' to the CVSROOT/commitinfo file to prevent 
> anyone from doing a commit and modifying the repository.
> 2. Tar up the existing respository.
> 3. Read/write-protect the repository. This prevents anyone from 
> updating from the old repos.
> 3. Untar the repos it on the new server.

make sure to use the preserve permissions options, i.e., "-p" in gnu
This should be less error prone than trying to reset everything with

> 4. Remove the 'ALL false' from the CVSROOT/commitinfo file *on the new

> server*.
> 5. Have everyone run a script that modifies the Root files in their 
> working directory to point to the new server. (There may be a contrib 
> script that does this, but it's not to hard to write.)
> With all changes of this nature, I'd recommend testing the process few

> times before doing it for real. (Don't do 1 and 3 when you are 
> testing.) Ie, create a test working directory of your own, check out 
> files and make some changes, copy the repos to the new server, change 
> the Root files *just in your working directory* and test updates and
> When you're sure it works, do it for real.
> Make sure you have good backups before doing anything.
> There are other approaches that others on this list have proposed, 
> including having everyone commit before beginning the tar/copy, and 
> setting up your DNS so that you never have to change the name of the 
> server even if the hardware changes. These are described in the 
> archives in the last six months or so.

Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the
Power of Technology for the Warfighter

reply via email to

[Prev in Thread] Current Thread [Next in Thread]