On Mon, May 6, 2013 at 10:59 PM, Z W <mpc8250_at_gmail.com> wrote:
> Hi All
>
> We have been merging from trunk A to branch B; recently another branch C is
> created out of trunk A; trunk A is frozen and C has become the new trunk for
> us;
>
> We mistakenly co the trunk C and performed
> svn propdel svn:mergeinfo -R
> svn revert .
> svn commit -m "should not have done it"
>
> Now when we perform
> svn mergeinfo --show-revs merged http://some.url.com/trunk/C
>
> and
>
> svn mergeinfo --show-revs eligible http://some.url.com/trunk/C
Not sure if I fully understand your description. Are you running these
commands while still in the working copy of trunkC? Because 'svn
mergeinfo' normally takes both a source (URL) and a target, and if
target is not given, '.' is assumed.
> all the revision numbers that were shown after performing merging from Trunk
> A to branch B are no longer reflected in the lists of TrunkB-Branch B.
>
> In other words, all
> revision numbers in TrunkA-mergedTo-BranchB
> are not reflected/shown in
> TrunkC-mergedTo-BranchB
Well, it's possible that this is normal behavior given svn's current
design. Have you checked what those commands showed before you deleted
the subtree mergeinfo? Maybe they already showed nothing?
I really don't know if what you're trying to do will work. I'm not
sure that svn understands that trunkC is just the continuation of
trunkA, but under a new name. How can it tell the difference between
"just another branch of trunkA", and "a new trunk, with a new name"?
Now, perhaps that distinction doesn't really matter: in theory svn
should just as well be able to merge (and reintegrate) between two
branches, and perhaps know that some changes were already merged
before the second branch came into existence. But in practice? I don't
know. Maybe someone else on this list knows?
In the absence of definitive answers I have two suggestions:
- Try some local experiments. You should be able to test quite some
things without committing (just merging or reintegrating to a clean
checkout of X, Y, Z ... and verify the result in your working copy).
- The upcoming 1.8 release contains some improvements in this area
(see [1]). If 1.7 doesn't work for you, perhaps give 1.8 (RC 1) a try?
The first release candidate will soon be available.
> Are we in trouble ?
> How do we revert back ?
That's easy, just undo that revision: [2].
> Thanks
>
>
>
>
> 1- will the mergeinfo in Trunk A be copied over to Trunk C so that we can
> continue merging from Trunk C to branch B
The mergeinfo will be copied along from trunkA to trunkC, just like
anything else (files, properties, ...). Feel free to check for
yourself.
However, as said above, I'm not sure you can continue merging from
trunkC to branchB, acting just like nothing happened. The problem is
that branchB's mergeinfo literally contains "trunkA" in its
description. If you look at the svn:mergeinfo property, you'll see
things like "/trunkA:345-456" (meaning: revisions 345 til 456 were
merged from trunkA). I'm not sure if svn is smart enough to realize
that these merges also apply to trunkC's relation with branchB, since
those trunkA-revs are part of trunkC's natural history. Best to try
some experiments to find out.
> 2- would be there issues with merging back from Branch B to Trunk C ?
Same as above ... not sure.
[1] http://subversion.apache.org/docs/release-notes/1.8.html#auto-merge
[2] http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchmerge.basicmerging.undo
--
Johan
Received on 2013-05-07 01:57:10 CEST