[svnmerge] Bidirectional merging

[Raman Gupta]

Dale Worley wrote:
>> 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*.

This makes sense and I agree.

> 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.

Ok.

>> 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.)

I'm glad we agree its the Theoretical Right Thing :-)  Though I
understand your point about missing possible changes, I'm still not
convinced that it is not workable. In your description above, are you
talking about bi-directional merges? If so, I'd like to understand your
workflow, because right now I'm not seeing how *regular* merges between
bi-directional branches would result in so many conflicts/non-building
code. Don't your branches diverge to the point where the bi-directional
merging is unworkable?

Cheers,
Raman