On Mon, Jul 08, 2013 at 13:40, Stefan Sperling wrote:
> You could rewrite history, creating copyfrom pointers in old revisions.
> Create a new repository, create the common ancestor branch in the first commit, create the other branches as copies, and then replay your existing history on top of that using svnadmin dump/load.
> See http://svnbook.red-bean.com/en/1.7/svn.reposadmin.maint.html#svn.reposadmin.maint.migrate
> for more information.
Yep, I finished analyzing the problem.
There are 2-3 unconventional branches like:
r12345: A /app/version3
r12346: A /app/version3/feature1 (copy from /app/version2/feature1)
r12347: A /app/version3/feature2 (copy from /app/version2/feature2)
(Instead of a simple A /app/version3 (copy from /app/version2)
...
I' ll dump/load up to revision 12344, commit a proper copy, stuff 2-3 dummy revs to keep the same revision numbers,
and load the remaining after. This should go fine without too much trouble, while keeping history,
and maybe not invalidating working copies (I hope).
> The --ignore-ancestry switch also disables merge-tracking, which is not ideal in this case.
Indeed. That's not what we want !
> You could use the 2-URL merge syntax for the time being:
> svn merge ^/app/v2-dev_at_70081 ^/app/v2-dev_at_HEAD svn/v3-dev
> That should work since it won't trigger the new "automatic sync/reintegrate merge" logic in Subversion 1.8.
> However, it also requires you to keep track of the number of the revision number the v3 branch was last synced up to (r70081 in this example).
Of course, but it's tedious and error prone. We'll only use that if we can't find a better solution which properly tracks the mergeinfos.
--
Eric Estievenart
Received on 2013-07-08 14:17:49 CEST