Re: CVS Server migration Question

[Todd Denniston]

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