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

Making the following of links in cvs2svn optional would be a good
thing. I doubt there's any good solution that fits into Subversion
other than perhaps, when following links, implementing Subversion
copies from the link source to the link destination at the appropriate
revisions.

With link following I can migrate with the 'cloning' approach and then
get them to modify their approach to access shared material via
relative paths - at least with history intact that's an option that is
at least moderately viable.

Having discovered this little gem I also found they've modified ,v
files directly and made a few mistakes... Letting people have CVS repo
file-system access is a bad thing - someone's always sure they're
infallible.

Thanks all for the pointers. Hopefully any negative feedback from the
people responsible won't stop the migration plan.

--
Talden
On 5/3/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Talden wrote:
> > 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.
> >
> > [...]
> >
> > 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.
>
> The standard SVN approach would be to use svn:externals.  svn:externals
> has some well-known limitations.  For example, they may have to be
> adjusted manually when you branch or tag, and they can only work if
> everybody accesses the repository via the same protocol (http vs
> svn+ssh, for example).
>
> Currently there is no support in cvs2svn for setting svn:external
> properties.
>
> > 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.
>
> The latest official release of cvs2svn (1.5.1) ignores symlinks in the
> repository (i.e., doesn't follow them at all).  This behavior has been
> changed in the trunk version of cvs2svn, which follows symlinks as if
> they were normal directories.  (This behavior could easily be made
> optional if that were important to your conversion.)  But neither
> version tries to convert the symlinks to svn:externals or anything
> similar.  (I can't think of automated behavior that would make sense.)
>
> Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org