[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

How should I deal with this CVS to Subversion migration issue (and how is this done the Subversion way?)

From: Talden <talden_at_gmail.com>
Date: 2007-05-03 02:11:19 CEST

I have a possibly nasty situation in a CVS migration to Subversion and
I'm both unsure how to proceed with the migration and how this
situation would 'normally' be dealt with in the Subversion world.

Note: Many parts of the development are on windows though the CVS repo
is on linux. References to symlinks in this email are specifically
referring to links within the repository not symlinks created in a
working copy as a result of checkout.

Several different teams use the same CVS repo (with little content
overlap) and we'd like to move to Subversion. A couple of the teams
have this strange approach to sharing common code. We'd like to get
everyone onto Subversion because it would:

a. Allow a single SCM solution
b. Allow unified product tagging (though the teams operate largely
independently as far as content (and technology) are concerned, a
product release spans all of these projects).

The weirdness comes from the example below which shows that the CVS
repo contains a number of symlinked RCS files (and some folders) - The
repo looks something like this.

      common1api/ --> ../common1/api/
      common2api/ --> ../common2/api/
      a.h,v --> ../common1/a.h,v
      b.h,v --> ../common2/b.h,v
      common1api/ --> ../common1/api/
      a.h,v --> ../common1/a.h,v

1. How would you achieve the same results in Subversion - Are
externals relevent? Can externals be used for these file-links. Is
there a redbook entry for this kind of issue? Is there a redbook
equivalent specifically covering CVS->Subversion migration issues and
changes in approach.

2. How is cvs2svn going to migrate this? Will it follow the symlinks
and just replicate shared content? This would 'unshare' the code
making future changes to common code fail to propagate automagically
but it would result in valid history at least.

To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 3 02:11:41 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.