On Thu, Jul 18, 2013 at 2:47 AM, Badipatla, Venkata <
venkata.badipatla_at_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.
Received on 2013-07-18 13:46:28 CEST