Stefan Sperling wrote:
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?
You guessed right. I have been able to figure with the developer that
commited the problematic merge how he actually did it: he used a
"clever" integration function of Eclipse. He's got no clue what he did
really and I'm not using Eclipse so I dont' either. I guess I'm not
going to investigate further. I just told him to control hat he commits,
not to commit empty files, but revert them instead.
I've created a new Feature branch from the trunk and copied the few
commits by hand. It was faster in the end. But I'm really happy to have
learn so much thanks to you.
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
That's a very good one to know. I guess, almost all modifications made
on a Release branch (in our case at least) should made their way to the
trunk. Except the one made on the pom.xml when releasing.
As far as i can see, for this reason only we need to do cherry picking.
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'm very glad to know that, I was afraid that scenario wouldn't be
supported by SVN. We definitely need that for the reasons I mentioned above.
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.
Maybe o all the merges myself ! But that's a lot of work...
/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?
I've tried, but not working. SVN doesn't find anything to merge.
I've discovered the --record-only option in the Svn-book. It seems it
could help with my problem, but it seem dangerous to use and their
examples are not enough for me to be confident on using it.
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
Thanks a lot for the time spent.
Jean
