On Thu, Jul 18, 2013 at 2:47 AM, Badipatla, Venkata < venkata.badipa...@capgemini.com> wrote:
> Hi Team,**** > > ** ** > > We are planning to migrate Clearcase vob’s to Subversion in Linux and > Solaris environment.**** > > ** ** > > Could you please let me know the good approach to do this activity.**** > > ** ** > > Thanks in advance!**** > > ** ** > > Thanks & Regards,**** > > _ > I've been through this with a number of companies, migrating from CVS and several weird, in-house, custom built, proprietary source control systems to Subversion. I'd suggest: * Build some practice repositories on Subversion first to get experience. Learn the basics of Subversion clients and servers and backup before you start serious planning. Look at good clients (like TortoiseSVN for Windows users), servers (such as using svn+ssh or Apach based HTTPS on Red Hat based server, etc.) And look at public projects with good workflow and tool suites, like sourceforge.net. * Strongly consider the commercial versions of Subversion to get support if you don't have serious sysadmin support in house. I was the support in house, and my time was fairly expensive. If you're a busy admin for a big company, using something like Wandisco's commercial version of Subversion gets you high availability and multi-master support and someone commercial to call about problems. * Find out what kind of workflow people want. Do they want lots of branches to do individual work on, and a central manager of a trunk to accept code reviewed changes? Or do they just want everyone writing directly to the same trunk? Should the build system publish daily tags, or do tags only occur with release versions? * When ready to migrate from the old source control, do a clean dump of the old system, and svn import into the new system into a branch, and make a locked *tag*. Do not *bother* with the old history. There's been huge amounts of time and effort burned with tools to migrate CVS or RCS or Perforce, and I'm sure there are some for Clearcase. But the impedance mismatches are deadly, especially if there's old bugs in the old repository. (Been there, done that: got screamed at because I edited a CVS source file to remove a manual edit someone had done 10 years ago that broke the cvs2svn tools because it was invalid CVS.) Mostly, no one *cares* about the old system's history after the migration happens. You'll save an enormous amount of complexity by just doing a clean import of the source code and allowing it to set svn:'eol as needed, and svn:keywords as needed, and leaving hte history in the old system for reference if anyone actually cares. * Under no circumstances maintain parallel work for the same project in Subversion and in the old Clearcase, and expect the Subversion history to be reconcilable with the parallel Clearcase history except by throwing out the Subversion repo and starting over from an import. If I meet one more oh-so-clever person who thinks reconciling such things is just a matter of a few lines of perl, I will throttle them with their own intestines.