[Svnmerge] Re: Bidirectional merging

[Jim Fulton]

Raman Gupta wrote:
 > The svnmerge tool is great. Thanks.

Yup

 > I have a question about bi-directional merging. Its not working the
 > way I expect but perhaps I am doing something wrong.
 >
 > Lets say I have:
 >
 > repo/trunk/
 > repo/branches/branch
 >
 > 1) Branch and trunk are init'ed after the branch is created.
 >
 > 2) Some changes are made on the branch and merged to trunk using svnmerge.
 >
 > 3) Some changes are made on the trunk.
 >
 > 4) Now, switching to the branch and running "svn avail" gives me all
 > the revisions on the trunk since the init, including the revision in
 > which the branch changes were merged to the trunk. Therefore,
 > attempting to do the merge results in the changes that were originally
 > made on the branch being re-applied to the branch again.
 >
 > This sometimes is not a problem for the merge (because the SVN merge
 > algorithm realizes the change was already applied) but more often than
 > not it does cause a problem.

I've run into the same problem, which has been a show stopper for me.
In follow ups to Raman's note, there was some disagreement about
whether the conflicts that sometimes arise are "bogus".  If there is
still any doubt, I suggest considering what one would do manually.
When manually managing parallel branches, having merged a change from
one branch to another, I would never considering merging back the
merge. To do so would be silly.  In fact, doing so would lead to an
infinite set of merges because each merge to one branch will become
available for merging back to another.  There is no good reason for
svnmerge to consider a change merge to be available to the source
branch.

IMO, the solution to this problem is straightforward.  When we merge
and commit a change, we record the committed revision as already
merged into the source branch.  The downside, of course, is that we
have to check out and commit a property change to the source branch as
well as checking out and merging into the destination branch.
Because the change to the source branch is so simple however, I think
this can be readily automated.  I think the benefit of making
bi-directional merging work far outweighs this downside.

Later, referring to a similar solution from Raman, Dale Worley wrote:
 > Unfortunately, that won't really work either.  When merging a change or set
 > of changes from one branch to another, it is relatively common that some
 > further additional tweaking to the WC has to be done before the merged
 > change is in shape to commit.  So even though rev A of branch X is labeled
 > "merge rev B of branch Y", it often is more than just that.  Thus we cannot
 > assume that rev A of branch X need not be merged back into branch Y, as the
 > tweaking in rev A may clean up some problem that is still present in branch

First, I'll observe that in my experience, I almost never have to
modify a merge.  Of course, I'm willing to believe that for some
projects this is more common. Even when I do make a change, it is to
address conflicts only.  I never make additional changes that I would
want to merge back to the source branch. If I needed to make
additional changes, I would make them in a separate commit, if at all
possible.  While I admit that there is a small chance of a loss of a
change, for me, the risk is acceptable.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org