[svnmerge] Bidirectional merging

[Dale Worley]

> From: Raman Gupta
>
> So you are OK with spurious conflicts?  It is obvious that all merges
> may require intelligent intervention, but that intervention should be
> limited as much as possible to "real" conflicts. Not
> conflicts that are
> present simply because the tool being used does not support merging
> changes on changes.

Well, by definition spurious conflicts are not a good thing.  But it seems
to me that the tool should err on the side of referring *too many* things to
the user than *too few*.

The correct solution would be to have "svn merge" be able to detect the case
of "changes on changes" and resolve it correctly. -- Actually, that is part
of the problem we're seeing, "svn merge" flags as conflicts a considerable
number of situations that it really should be able to resolve automatically.

> 1) I think you're trying to argue that because the solution does not
> solve 100% of the possible merge scenarios, that it is not a good
> solution.

I'm particularly worried about solutions that might cause a change to be
overlooked for merging, much more than I'm concerned about svn detecting a
conflict when it need not have.

> 2) Even in situations where those "tweaks" are common, your procedures
> can change in simple ways to avoid this issue:
>
> a) you can commit the merge first, and then apply the tweaks
> so that the
> tweaks will be available to merge back to the branch later. This
> solution of course doesn't apply to conflicts that need to be resolved
> before the commit, but if you've got major conflicts between
> bi-directional branches then you've probably got bigger problems and
> need to re-synchronize the branches manually.

We've seen a relatively large fraction of merges that contain conflicts
(which of necessity can't be checked in) or which cannot be built (which
should not be checked in), so I'm not convinced that this method can be made
to work.  (Despite that it's clear that it is the theoretically Right Thing
to do.)

Dale