Talden,
Have looked at this issue for some time now, I found the the solution that
worked best (atleast in my situation) was to create empty directories in
place of the symlinks and then use "svn switch" to point these directories
to the actual component locations.
A typical process would be ==>
-- copy over the cvs files and remove all the links
-- run cvs2svn through all the cvs files and generate svn repository
-- create empty directories in place of links ( in the svn repository )
-- checkout the trunk
-- run "svn switch URL/project1/common1api common1api" in your workarea for
each symlink
[ this is a client side activity -- different from CVS! ]
* eventually you would have to create a script that developers can run
after co*
-- create a branch from your workarea [ svn clones your workarea ]
cheers
murli
P.S: Externals never worked the way I needed it to --
> -----Original Message-----
> From: Talden [mailto:talden@gmail.com]
> Sent: Wednesday, May 02, 2007 5:38 PM
> To: Jens Schmidt
> Cc: Subversion Users; cvs2svn Users
> Subject: Re: How should I deal with this CVS to Subversion migration
> issue (and how is this done the Subversion way?)
>
>
> Actually I have cvs2svn running on the linux machine successfully on a
> portion of the repository. This finally runs as I'd expect and I've
> begun refining the options file to standardise branch and tagnames,
> filter content, etc. Estimated runtime for the whole (only a guess
> based on linear scaling of the portion I've tested) is about 48 hours
> to produce a dumpfile. I have no idea how long the dump-file will
> take to load yet.
>
> Due to path lengths the CVS repository cannot actually be copied to a
> Windows machine. Currently this poses no problem as I'm not using
> Windows for the conversion though Windows will be used by many
> developers checking out portions of the Subversion repository - you
> also cannot make working copy of the entire repository on Windows due
> to the same path length limitation in the NTFS filesystem.
>
> Now that I'm ready for a larger test run I've run into this odd
> symlinks situation and I need to know how to resolve it. Failure to
> find a solution might actually give another team enough leverage to
> block the migration entirely.
>
> --
> Talden
>
> On 5/3/07, Jens Schmidt <JensS@dyno.com.au> wrote:
> > Here is what I did to convert our existing CVS to SVN using cvs2svn.
> >
> > In order to run correctly (on windows!) cvs2svn requires the following
> > tools
> >
> > * unix tools (UnxUtils.zip + UnxUpdates.zip). You must update the path
> > environment variable so the UNIX sort tool comes before WINDOWS sort.
> >
> > * RCS is recommended for the conversion. You must update the path
> > environment variable to point to the co tool.
> >
> > Copy CVSROOT from old linux server into a temporary location. Open a
> > Command prompt and execute the following commands. Make sure you update
> > the path accordingly.
> >
> > set path=C:\RCS\bin\win32;%path%
> >
> > cvs2svn.py -v --existing-svnrepos -s c:\repository C:\Temp\cvsroot
> >
> > Hope that helps
> >
> > Jens
> >
> >
> >
> > -----Original Message-----
> > From: Talden [mailto:talden@gmail.com]
> > Sent: Thursday, 3 May 2007 10:11
> > To: Subversion Users; cvs2svn Users
> > Subject: How should I deal with this CVS to Subversion migration issue
> > (and how is this done the Subversion way?)
> >
> > 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.
> >
> > cvsroot/
> > dev/
> > common1/
> > api/
> > ...
> > a.h,v
> > common2/
> > api/
> > ...
> > b.h,v
> > project1/
> > common1api/ --> ../common1/api/
> > common2api/ --> ../common2/api/
> > a.h,v --> ../common1/a.h,v
> > b.h,v --> ../common2/b.h,v
> > ax.c,v
> > bx.c,v
> > project2/
> > common1api/ --> ../common1/api/
> > a.h,v --> ../common1/a.h,v
> > ax.c,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.
> >
> > --
> > Talden
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.463 / Virus Database: 269.6.2/785 - Release Date:
> 5/2/2007 2:16 PM
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu May 3 03:04:02 2007