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

I absolutely think that immediately following migration the team will
need to reorganise their project. Getting traction for migrating them
at all requires that the migrated content is itself correct for all
previous releases. This will be the case just by following links and
replicating content, but I was merely musing on the prospect of also
being able to indicate in the history that the code originated in the
shared base.

I'm not going to promote externals to them. I'm going to recommend
that they clearly define a 'core' project that is more obviously
shared and has release management (albeit only internal release
management). This way they don't have one project developing against
a moving target motivated by the demands of what should be another
projects independent life-cycle.

Thanks for the help... I'll take a peek at python and see whether I
can figure out how to make the link following optional.

--
Talden
On 5/9/07, Michael Haggerty <mhagger@alum.mit.edu> wrote:
> Talden wrote:
> > 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.
>
> This would make the result of the conversion look kindof OK, but the
> first post-conversion commit to one of these files would cause the
> files' contents to diverge; therefore it doesn't seem like a very useful
> approach.
>
> Perhaps you should consider treating the shared content as a separate
> "library" project with its own version numbers, etc.  Alternatively,
> there are tools that can be used to make working with svn:externals
> tolerable.
>
> Michael
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org