>
Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851 VAT Reg No 778499447 -----Original Message----- > From: barveanike...@gmail.com [mailto:barveanike...@gmail.com] > Sent: 11 December 2009 13:20 > To: us...@subversion.tigris.org > Subject: Re: Migration to SVN > > Hi All, > > I am also working on a big project to migrate our source code > from an old system (CMS running on VMS OS) to Subversion. > > So could you please tell me what process you have followed > for CMS to SVN MIGRATION? > > I want know below mentioned points. > 1. How CMS data is exported to local directory. In my case I > have around 1000 elements do take copy of each element > manually its very time consuming & critical job. > 2. Suppose once you have exported data to local directory. > Then what is the procedure to export data to the subversion. > Well, I did it 2 years ago so I don't remember everything. First of all, we were happy to lose the history of the files. It's not completely lost as CMS keeps the log at the top of each file. What I mean is that we accepted the fact that it would not be possible to get back to an old generation of a file. If you want to do that I think it's still possible to migrate to Subversion but I don't know how and it's probably too much effort. Roughly this is what we did. We had 3 or 4 versions of our application. For each versions we had two streams: dev (used by developers) and cand (use by testers). Changes were merged from dev to cand by testers to produce a candidate release. Each new version was created copying the previous version cand stream into both the new version dev and cand streams. Then the changes that were in the previous dev but not yet in the previous cand were merged into the new dev. This could be summirise by something like the following: - copy version A cand into version A+1 dev - copy version A cand into version A+1 cand - for every change in A dev but not in A cand merge the changes from A dev to A+1 dev Based on the above I came up with a process to migrate from CMS to SVN. Note that we wanted to have a one-way merge and copy, so instead of copying A cand to A+1 cand, we copied A+1 dev to A+1 cand, which is effectively the same but result in all changes to a cand coming from a dev. Another aspect we were interested in was to keep a chain of history between the various versions. We wanted each file to be linked to itself in the previous versions. This is natural in Subversion but not so much in CMS (in my view). The main idea was to create the first version with normal import, and the subsequent ones as copy of the previous versions plus what has changed. This will save a lot of disk space (as copies are cheap in Subversion) and create that link between versions that we wanted. For simplicity let's call the versions 1, 2, 3 and 4. The cand strean on version 1 in CMS will be called CMS-1-cand (and similarly for the dev stream and for SVN). The process went something like this: - extract CMS-1-cand and import it into SVN-1-dev (These was the only time we made an immport) - copy (using Subversion) SVN-1-dev in SVN-1-cand (Remember, we wanted all cand streams to be a copy of dev as a start) - extract just the files that were in CMS-1-dev but not in CMS-1-cand and, using a WC of SVN-1-dev, commit the changes (in SVN-1-dev) At this point the first version, both dev and cand stream, is the same in CMS and SVN. For every other version it works in a similar way, like this, so let's use x and y as previous and next version. - copy (using Subversion) SVN-x-dev in SVN-y-dev - copy (using Subversion) SVN-y-dev in SVN-y-cand (Remember, we wanted all cand streams to be a copy of dev as a start) - extract just the files that were in CMS-x-dev but not in CMS-x-cand and, using a WC of SVN-x-dev, commit the changes (in SVN-x-dev) - repeat for the next version (so x becomes y and y becomes y+1) To make this easier and quicker we made sure that as few changes as possible were in dev but not in cand. We used are track system for that, and since it's an in-house one, I can't really help you with that. Finally, sorry for the big delay. Good luck Giulio
