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 Raj ---------
On Mon, Dec 8, 2008 at 9:55 AM, Todd Denniston < [EMAIL PROTECTED]> 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 >> 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 >
