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

I wonder what is involved in making the migration treat these internal
cvs repository links as svn copies from the source. This would
produce a marginally smaller repository (since it only saves the first
revisions content in the copies) but it would explicitly show the
historic source of the content.

So links are followed but clearly reference back to the shared source
material... If we were able to leverage merge information coming in a
later Subversion you might even manage better info.

source/a.c
linked/a.c <-- source/a.c

lets say that the source/a.c is modified in revisions 1 and 2... The
following might be the emitted dump

r1
add source/a.c
copy source/a.c linked/a.c
r2
commit diffs to source/a.c
merge source/a.c linked/a.c

Without the merge support there's no way to clearly show that the r2
commit in linked/a.c originated from source/a.c but at least the
original copy will show the source location in the history.

Yeah yeah, I know, dream on, tiny edge-case for people who created
their own insanity by managing their CVS repo this way.... Sigh... I
can dream.

--
Talden
On 5/4/07, Talden <talden@gmail.com> wrote:
> 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