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
Received on 2010-05-12 07:40:30 CEST