-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [EMAIL PROTECTED] wrote: > I have a couple of questions. > > My current situation is I started working at a company with a solaris 8 > box that has a cvs repository on it. The box is old is being replaced > by a muh newer box. The long and the short of it is that I need to get > cvs off of the old box and onto the new box. > > The problem, ... I have never used or worked with cvs ... ever. > > What I think I know: > CVS runs on the solaris box as the cvs user. > It is started as part of the inetd service. (entry below) > cvspserver stream tcp nowait cvs /usr/local/bin/run.cvs > > The run.cvs file sets a variable that contains all of the repositories, > and then runs the following > exec /usr/local/bin/cvs -f $myrepository pserver > > the myrepository variable looks something like this > myrepository="--allow-root=/cvs/repository1 > --allow-root=/cvs/repository2 ..... " > > The /etc/services file has the following 2 entries > cvspserver 2401/tcp > cvspserver 2401/udp > > ** Currently, the server running cvs is on a unix domain. The new > server will not be on a unix domain. > > Now .. Getting slightly more comlicated, and more into the unknown. > How are the users for cvs created. From the reading I did, it looks > like they might be somehow created from the passwd file. It is my > intention to not create a username on the unix server for every user > that has access to cvs. > > Question1. Is there a way to create users in CVS without using the > /etc/passwd or yppasswd files? If so, How.
http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_2.html#SEC9 should answer a lot of your questions. > Question2. How do I get the cvs user accounts from the old server to > the new server. Copying $CVSROOT/CVSROOT/passwd and users to the new machine should do it. > Question3. As far as transfering the CVS repository from one server to > the other, can I just tar up the directory, and transfer the tar file ? Yes, that's the basic idea. > Question4. What else am I missing. Backups, before and after the move. You *must* make the old repository read-only before you start. Otherwise you run the risk of users checking in data to the old repository during the move, or some users checking in data to the old repository while others check in to the new repository. You can make it read-only by using o/s permissions, or (if you're using pserver) creating an file $CVSROOT/CVSROOT/writers (see section 2.10 of the link I provided above), or by using the cvs_acls script (it's in the contrib/ directory of the source code distribution). Review any trigger scripts, such as commitinfo, loginfo, etc. to make sure they run properly on the new platform. Make sure everyone has checked in their changes before you start the process. They'll need to do a fresh checkout once the move is complete. Schedule the changeover to minimize the disruptions to your users. Do a dry run first, to iron out the bugs. Create a DNS alias, so that your repository is independent of the machine's actual name. Then, in the future, migrating will be simpler - just copy, test, switch DNS entries, and away you go. - -- Jim Hyslop Dreampossible: Better software. Simply. http://www.dreampossible.ca Consulting * Mentoring * Training in C/C++ * OOD * SW Development & Practices * Version Management -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFD/KTKLdDyDwyJw+MRAmrvAJ9bwZrkEiHhjPeRgWL55gG3hAsQnQCfQTfh HyQ6FgC93P/S8bBtv5XlgrY= =Kmy6 -----END PGP SIGNATURE----- _______________________________________________ Info-cvs mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/info-cvs
