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. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed May 10 00:04:26 2006