|Subject:||RE: CVS Unix to Linux Migration|
|Date:||Wed, 4 Feb 2009 14:35:41 -0800|
> 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.
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
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|