On Tue, May 11, 2010 at 12:06:50PM +0800, Jean Seurin wrote: > Hi Stefan > > first of all thanks for spending the time for this long thorough analysis. > > 1) I want to state that we're using a range of different SVN > clients, cli, Intellij Eclipse, mainly, and some people under > Windows may use Tortoise - bu those usually don't venture into > merges - yet. > I tought at first it could be the cause of the problem, since I have > had bad experiences with SVN clients on some IDEs. > But after reading through your whole analysis, I think I get where > the problem comes from. Here's our setup right now: > > [copy] [merge of bugfix r4 only] > release-branch-1.13--r2---r4------------------ > / \ > trunk -----------r1----r3------r6------------------ > \ \ \ / [--reintegrate not > possible anymore] > feature-branch-dev-r5------r7--------- > [copy] [merge] [merge] > > Hope the drawing make sense: we have to merge back bug fix from > /release branch/ back to trunk. We don't really have to use merge > command for that, but some developer start to take a fancy into it > and uses it to merge a revision only, that corresponds to a bug fix.
Can you state which revisions were merged where in your example? I guess r2 is the commit which was not merged back into trunk? How was the merge from release-branch-1.13 to trunk in r6 done? If you want all changes that happened in the release branch merged to trunk, you can use --reintegrate for that, since the merge is going into the opposite direction to the branch copy. But there's a catch: if you want to reintegrate multiple times (to merge more bufixes later), you have to use the trick described here: http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice Or you can do a cherry picking merge (grab one or more revisions like your developer did). But cherry picking should only be done into a single direction (mostly to keep things simple and prevent developer insanity, but also because it makes merging with svn easier). So if you ever cherry-picked one way, do not cherry pick the other way. The canonical way to do the cherry-pick would be: cd trunk-working-copy svn merge -c 6 ^/release-branch-1.13 > If I follow you - and that would make sense - once this merge to > trunk makes its way to the /feature branch/, this one becomes not > 'reintegratable' anymore. It depends. I'm still not entirely sure I understand your example. If you could describe how each of the merges was (reintegrate merge, sync merge, cherry-pick merge) that would help. > This use case appears to be quite regular to me. If it is not > possible to use it, it'd be better to know it before using /Feature > branch. It is possible to use features branches and release branches at the same time. Merging bug fixes from the release branch to the trunk should not prevent reintegration of the feature branch. That alone does not explain the problem. I still think it's more likely that your problem is due to the scattered subtree mergeinfo on trunk and possible the project-dev branch. The mergeinfo shows "holes" in the merge history between project-dev and trunk. These holes need to be filled before project-dev is ready for reintegration. I don't think a single cherry-picking merge from an unrelated branch would cause this problem. > /2) How can I solve my problem? > It seems from the reasoning above that the right solution would be > to do a complete merge of the Release branch 1.13 to the trunk - > instead of just a revision. I doubt that is possible for us. > If not, what are the options left? / Making sure merges into your project-dev branch from trunk cover a continuous revision range is your best option I think. > /I want to get rid of the subtree mergeinfo - for those blocking > files, they seem to have been commited by mistake anyway- to keep > only the trunk root mergeinfo. Can I delete them manually? > If not how to get rid of subtree mergeinfo? In general, do not delete mergeinfo yourself. In some cases, where mergeinfo was created by accident (seems to be the case in your situation), you can delete mergeinfo if and only if there exists mergeinfo above it which is inheritable (does not have a *) and is a superset of the mergeinfo below it. E.g. this subtree mergeinfo is safe to delete: trunk [svn:mergeinfo = branch1:r4-50, branch2:r30] src foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo But this isn't safe to delete: trunk [svn:mergeinfo = branch1:r4-50] src foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo and this also isn't safe to delete: trunk [svn:mergeinfo = branch1:r4-50*, branch2:r30*] src foo.c [svn:mergeinfo = branch1:r10-25, branch2:r30] <- subtree mergeinfo Have you tried the merges from trunk to the project-dev branch I suggested in my last mail? What happened when you tried them? Did they help? > Even using the regular scenario, it seems some mergeinfo never > disappear. For instance: > > Properties on '$REPO/trunk/commons-client': > svn:mergeinfo > /branches/commons-opapl-dev:6352-6355 > /branches/commons-client-test:6346-6349 > These two branches were test feature branch: they have been > reintegrated and deleted already. > > Is that regular for SVN to keep all those infos about deleted branches? Yes, of course. It's part of the history of your repository. Don't worry about that. That's totally fine. In fact, if you remove those branches from mergeinfo you'll break commands like "svn log -g". > 3) I have long lasting development Feature branches that I don't see > any mention of in the mergeinfo. When are mergeinfo actually > created? Mergeinfo is created at the merge target when you do a merge. Stefan
