[svnmerge] Bidirectional merging

[Raman Gupta]

Dale Worley wrote:
>>From: Raman Gupta
>>
>>
>>>Yes, this is a "known problem".
>>
>>Hmm, too bad. I think that "bidirectional merges" are a no-go for all
>>but trivial cases until this is resolved.
> 
> I don't see it that way.  But I assume that all merges may require
> intelligent intervention.

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.

>> I feel your pain. I think what needs to be done is to store the
>> revision numbers of merges (or merge-points) somewhere, so that we
>> can exclude those revision(s) when merging back.
> 
> 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
> Y.

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. The situation you describe is common in some workflows, but
not in others. With bi-directional merging, the intention is normally
that the branches stay as close together as possible. In this use case,
the limitations you are raising are simply not that important.

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.

b) you can undo the merge, switch back to branch Y, resolve whatever the
issue is on branch Y, and then try the merge again.

Cheers,
Raman