On Tue, 09 May 2006, Ben Collins-Sussman wrote:
> On 5/9/06, Hayward, Michael A <michael.a.hayward@sun.com> wrote:
> >----------------------------------------------------------------------
> >svn cp http://vortex/play/trunk http://vortex/play/branches/bintest
> >svn co http://vortex/play/trunk
> >svn co http://vortex/play/branches/bintest
> >cd trunk
> >cp /tmp/binaryfile .
> >svn add binaryfile
> >svn commit -m 'added MoneyBag'
> >cd ..
> >cd bintest
> >svn merge -r4:5 http://vortex/play/trunk svn commit -m 'svn merge -r4:5
> >http://vortex/play/trunk'
> >cd ../trunk
> >svn update
> >svn merge -r4:6 http://vortex/play/branches/bintest
>
> Here's the problem.
>
> I'm familiar with your model, we do it all the time. For example,
> sometimes we'll have a long running feature-branch. Once a week we'll
> merge all of the trunk changes to the feature branch, just to keep the
> branch from drifting too far away from the main code. Then, when the
> feature is done, we'll merge the branch back to the trunk.
>
> The problem here is that your command to merge the branch back to the
> trunk is too expansive: you're hitting the 'repeated merge' problem
> here. You're merging a change to the trunk which the trunk *already
> has*. Don't Do That. Instead, you should be running
>
> cd trunk-working-copy
> svn merge trunkURL branchURL
>
> In other words, because the branch already has all of the trunk
> changes in it, you should be asking merge to compare the latest trunk
> tree with the latest branch tree: the resulting diff will be *only*
> those changes made to the branch. Chapter 4 in the book specifically
> discusses this use case.
>
> So yes, you're hitting issue 2403. But on the other hand, you
> shouldn't be trying to merge redundant changesets like this. Fix your
> process. :-)
Fixing your process is definitely a valid work around, but eventually
the Subversion can automatically support this use case.
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Wed May 10 18:36:02 2006