info-cvs
[Top][All Lists]
Advanced

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

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


From: Todd Denniston
Subject: Re: moving a CVS repository to a newer/faster Linux box
Date: Thu, 17 Nov 2005 10:01:42 -0500


"Mark E. Hamilton" wrote:
> 

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

> 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 CVSSERVER.my.domain.com, 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 tar.
This should be less error prone than trying to reset everything with
chown/chmod.

> 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 commits.
> 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]