RE: CVS Unix to Linux Migration

[Rez]

> Date: Wed, 4 Feb 2009 09:58:47 -0500
> From: address@hidden
> To: address@hidden
> CC: address@hidden
> Subject: Re: CVS Unix to Linux Migration
>
> Rez wrote, On 02/04/2009 12:49 AM:
> > Hi Everyone
> >
> > I'm in the midst of migrating our current repository
> > from an old Solaris box
> > to a new Redhat(CentOS 5.2) linux box.
> >
> > CVS is installed, configured, and all set up on the new server.
> > Users have been re-created and setup in /etc/passwd.
> > I created a test Repo and from a Windows client machine
> > using WinCVS I managed to connect via the
> > pserver method and checkout a project/module successfully.
>
> I assume this means you have modified the /etc/xinet.d/cvs file correctly and
> thus inet recognizes calls to it on 2401.
 
Yes, I can both telnet to the port and connect via a cvs client to the server. Would you please check the content of my file to make sure it's ok, thanks:
 
$ cat /etc/xinetd.d/cvs
# default: off
# description: The CVS service can record the history of your source \
#              files. CVS stores all the versions of a file in a single \
#              file in a clever way that only stores the differences \
#              between versions.
service cvspserver
{
        disable = no
        port                    = 2401
        socket_type             = stream
        protocol                = tcp
        wait                    = no
        user                    = root
        passenv                 = PATH
        server                  = /usr/bin/cvs
        env                     = HOME=/cvs
        server_args             = -f --allow-root=/cvs pserver
#       bind                    = 127.0.0.1
}

2 questions:
 
1. is cvs is a reserved word or could I or should I call a repository cvs or can it be part of a path /repo/cvs/proj?
2. in server_args, is the placement of the -f parameter ok?

>
> >
> > Could someone please tell me:
> >
> > 1- if the migration is more involved than simply tarballing
> > the repository from the old server and untarring and
> > mounting it on the new server?
> > Meaning, the repository is independent and not affected
> > by the old OS in any way as far as file system or
> > formatting or any other thing go.
>
> The file structure should be good.
> The permissions/ownership may need to be tweaked if all the names/UID/GID of
> the users do not match from system to system.
>
> > What else do I need to do on the old server to prepare?
> On the old server, I would disable cvs in /etc/inet or /etc/network/inet
> (where ever the Solaris you are working with hid it's inetd config) and
> restart inetd... BEFORE making the final tarball to put on the new machine.
> Reason: you don't want to loose any changes someone makes while you are
> turning on the new machine.
 
Good point, thanks.

>
> >
> > 2- Because it's a migration by way of untarring,
> > do I still need to execute "cvs -d /repo/path init"
> > since the existing repo already contains the CVSROOT directory?
>
> It is still a good idea, because by doing that cvs will create, with default
> settings, any new config files that did not exist when the old cvs was made.
 
Will do, thanks.

>
> >
> > 3- Also, I would like to get rid of some old projects
> > in the repository before I migrate it, we don't need
> > the history and don't need to save them,
> > so could I just log into the old server as Admin and
> > do an rm or mv command (carefully of course) w/o
> > trashing or corrupting the repository?
>
> rm or mv in the repo is by definition "corrupting the repository". :)
> I would on the new server, build a script that did appropriate rm's based on
> where you are putting the final repo and what you know needs to go away, then
> when you untar the last tarball, run the script on the new repository.
> This way, if you quickly figure out you made a mistake, you still have
> everything as it was on the old server.
> Summary: keep the old server as it was, so it is a back up to the backup. :)
>
> >
> > Thanks all
> >
> > Rez
>
> --
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane)
> Harnessing the Power of Technology for the Warfighter

---

Windows Live™: E-mail. Chat. Share. Get more ways to connect. See how it works.