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
Received on Wed May 9 09:56:42 2007