> Date: Wed, 4 Feb 2009 09:58:47 -0500> From:
> [email protected]> To: [email protected]> CC:
> [email protected]> 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.
http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t2_allup_howitworks_022009
