[Top][All Lists]

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

Re: CVS Server migration Question

From: version wizard
Subject: Re: CVS Server migration Question
Date: Mon, 8 Dec 2008 22:15:21 -0800

Thanks a lot Todd for a very detailed response.
With some playing around  we discovered #3.
 But you have given us a lot more choices.
This is much appreciated.
best regards

On Mon, Dec 8, 2008 at 9:55 AM, Todd Denniston <address@hidden> wrote:
version wizard wrote, On 12/01/2008 08:03 PM:

Hi All

We are upgrading from old cvs version
Concurrent Versions System (CVS) 1.11.5 (client/server)
To Newer cvs version
Concurrent Versions System (CVS) 1.11.17 (client/server)
We have a new Linux Server with a newer RHAT OS and newer
CVS version 1.11.17

We plan to attach the CVS SAN storage with cvs repository to the
new CVS Server and ask the users to change the CVSROOT variable
to access the CVS repositories using the new CVSROOT variable.
The repository name/repository access path all remain same, JUST
the servername will change in CVSROOT variable.

The question I have is what happens to the workspaces and checked out files/
uncommitted files in the workspace checkedout with OLD CVSROOT variable
after the upgrade?

They are left in the cold.

Will Developers be able to commit these files OR do they have to manually
merge? Or if this is not an issue? OR if it is an issue how to resolve it.
Please advise
thanks in advance

There are four ways I see for handling your situation:
0) beat the admins around the head until they understand that there should be a service name (CNAME) in DNS for the CVS server so that when it comes time to do the transition from one physical machine to another all that has to be done is change DNS.  A logical CNAME would be ... cvsserver

1) make 'working/sandbox' branches for the developers and have them check in to that until the transition is done or the work is ready for general release.
In this way hopefully there will be no changes or new files that exist only in sandboxes at transition time.

2) have both machines up for a while, but have the OLD machine mount the SAN read only so that folks can produce patches from their old sandboxes and apply those patches to new sandboxes.

3) each developer will, in each of their sandboxes, need to run something like the following:
for i in `find . -type d -name CVS `; \
do \
 sed -e s/oldmachName/newmachName/ $i/Root > /tmp/tmpfile; \
 cp /tmp/tmpfile $i/Root ; \

As 3 is done by each of the devs, and I don't know if your old or new machine names might match something else in the Root files, I see 3 as the highest risk method.

with 2 the biggest risks are:
a) the admin will forget to change the SAN mount to read only on the Old machine before bringing up the new machine.
b) You have folks who don't know how to make (using --new-file) or use patches.

with 1 the largest risk is someone thinking they have done adds and commits but failed to actually do it.

with 0 the largest risk is that someone will be doing a commit when the DNS transition occurs on the old machine, and a second will begin another cvs writing operation using the new machine (similar to method 2's risk).  It would be best to a) set the TTL of DNS for the machines to be < 5 minutes, b) communicate when the transition would be happening to all the devs [suggest they get some tea or coffee while maintenance is being done], c) remount the repository read only on the old machine ~15 minutes prior to transition and then change DNS, d) set the TTL of DNS back to something reasonable.

Method 1 acts as a fallback for a broken method 0.
Method 2 acts as a fallback for a broken method 1.
Method 3 acts as a fallback for a broken method 2.

Good luck.
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]