subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric Estievenart <eric.estieven...@neolane.com>
Subject RE: Some sync merges no more allowed with 1.8 client ?
Date Mon, 08 Jul 2013 12:17:11 GMT
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@70081 ^/app/v2-dev@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

Mime
View raw message