[Svnmerge] Conflict on svnmerge-blocked property

[Raman Gupta]

Daniel Rall wrote:
> Yup, it definitely "fixes" this particular problem (I used your patch
> while developing the test case :).
> 
> However, I don't consider the change to be correct, because of its
> lossy handling of merge history.  At the time, we discussed some
> strategies which could be used to avoid the data loss -- one of those
> should be pursued instead.  I'm spending all my time developing Merge
> Tracking in Subversion's core, so haven't the bandwidth to spend on
> this myself.

Ok, and I for one certainly appreciate the work you're doing in
subversion core -- I am waiting with bated breath for the release of
1.5, and I would help out if I could...

IIRC, for svnmerge.py, the other solutions boiled down to the proper
handling of graph-based / transitive merging in svnmerge.py. I don't
think that is an easy thing to do in svnmerge.py, but am willing to be
proved wrong.

The solution I proposed is a stop-gap until 1.5 is released, and would
allow svnmerge.py to support bi-directional (not graph) merging
between any branch that had been explicitly initialized with
svnmerge.py, without loss of merge information related to these
branches, and without the transitive information messing things up (as
in Piet-Hien's blocked property conflict, which should be an easy
fix). It also supports cases like Auke's where the merging is
transitive, as long as each branch involved in the transitive path is
initialized with its "parent" branch.

The stopgap solution supports everything that svnmerge.py has every
claimed to support. And it covers probably 90% of merge use cases. Its
the old "don't let the perfect be the enemy of the good"...

If you still don't think the change is correct, ok. I for one am
perfectly happy with my patched svnmerge and I am willing to wait for
1.5 for the correct solution :-)  If Dustin, or whoever, will create
the test case, then I might update my patch to handle the blocked
property conflict too.

Cheers,
Raman