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 _______________________________________________ Svnmerge mailing list [email protected] http://www.orcaware.com/mailman/listinfo/svnmerge
