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
Received on 2010-05-11 13:00:57 CEST