[Svnmerge] [PATCH] Bidirectional merging patch for svnmerge.py

[Blair Zajac]

Giovanni Bajo wrote:
> Blair Zajac <blair at orcaware.com> wrote:
> 
> 
>>>This patch differs from my bidi patch to the original svnmerge by not
>>>using dot-files to store the merge revisions. It instead uses
>>>Archie's suggestion of checking the svnmerge integrated property.
>>>The upside to
>>>this is that no dot-files are required, the downside is that it is
>>>slow because it requires a remote svn diff call for each possible
>>>revision to
>>>be merged.
>>>
>>>Because it can be slow, and because it is only required in special
>>>situations (bidi merging), by default the reflected revision check is
>>>not done. I have added an option "-b" or "--bidi" to the avail and
>>>merge commands that must be specified if the user wishes to check for
>>>reflected revisions.
>>
>>The current behavior could be thought of as sub-optimal from a merging
>>standpoint (not from a performance point of view), so maybe we should
>>enable it by default and add an option to disable the bi-directional
>>support could be made as an optimization, for those people that know
>>they don't need it.
> 
> 
> I'm a little behind with patch and mail reading (I'll try to get in sync
> tomorrow), but let me state I'm -1 on turning this on by default if we don't
> find a way to implement it faster (there ought to be one!). I don't want to get
> to the point where people read the svnmerge property and run a manual "svn
> merge" because svnmerge is too slow and does too many things they don't
> understand/know/want.

As an optimization, we could have svnmerge.py store in a pickled 
~/.subversion/svnmerge.pck the revisions that have been merged from one 
directory to another and when the merge is done, it could be looked up in there. 
  If it's not found, then it's not a big deal, as svnmerge.py can always 
determine it the hard way, as we do now.

Regards,
Blair