On Mon, May 6, 2013 at 10:59 PM, Z W <mpc8...@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
