[Svnmerge] Patch for non-reflected bidirectional merging support

[Jim Fulton]

Raman Gupta wrote:
> Archie Cobbs wrote:

...

> If you agree with my assertion above that we only need to think about
> bidirectional cases,

I do. :)

> then we can simplify this *significantly* and
> remove the recursion.

Yup. Basically, just avoid merging revisions that changed
svnmerge-integrated.  This has the added advantage of not merging
"svnmerge init"-created revisions.

...

 > I think the only downside is that it will be quite a lot slower than the
 > dot-files implementation because it has to check the remote
 > svnmerge-integrated property for every candidate revision, instead of

I think it should be possible to speed this quite a bit by
doing an XML log on the range of candidate revisions to
find those revisions that directly modified the branch directory.

BTW, this should affect "svnmerge avail" as well.

and, in a later message you wrote:
 > Another possibility is to keep some sort of meta-data store outside the
 > repository in order to "cache" the results of merge-point checks. So,

I suggest that revisions you choose not to merge, you still record
in svnmerge-integrated.  That is, when you do a merge, you include the
reflected revisions you didn't really merge in svnmerge-integrated as if
you had merged them. Then you don't have to keep looking at them forever.
(Alternatively, use al alternate property.)

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org