[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS Server migration Question
From: |
Todd Denniston |
Subject: |
Re: CVS Server migration Question |
Date: |
Mon, 08 Dec 2008 12:55:11 -0500 |
User-agent: |
Thunderbird 2.0.0.18 (X11/20081105) |
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
RAJ
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 ; \
done
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