[Svnmerge] Bidirectional merges

[Raman Gupta]

Morten Lied Johansen wrote:
> If I merge from trunk into my branch, and then merge from my branch back 
> to trunk with no changes done in the meantime, shouldn't I be without 
> conflicts?

This is a pretty normal use case and I don't really see why you are
getting conflicts. Do you have artifacts like modified files on the
trunk that were renamed and modified on the branch? Since Subversion
doesn't yet have true renames, this can cause lots of problems. There
might be other similar "no-nos" that are causing this.

Also, what version of svn are you using -- svn 1.4 fixed a bunch of
issues with replaced files (e.g. a file that was deleted, and a
different file added with the same name), for example.

> Am I right in thinking that the reason for this problem is that the 
> changes I did to resolve conflicts when merging from trunk to my branch 
> are left out since they were committed in the same commit as the merge 
> itself?

Without seeing more details its hard to say, but your statement above
is definitely true -- any changes you made as part of the merge commit
on the branch will be considered reflected and NOT merged back to the
trunk.

> How do I avoid doing that without committing a merge that has unresolved 
> conflicts?

Change as little as possible :-)  A good rule to follow is that no
semantic changes should be made in the merge commit, because they
would then be lost for reverse merging. Resolve only the conflicts and
then make further changes in a separate commit. If the changes are
integration changes and should not be merged back, then you can make
them in the merge commit, or in a separate commit which you would then
 block. The latter allows unblocking at a later date, if you need.

Cheers,
Raman