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

[Raman Gupta]

Blair Zajac wrote:
> Giovanni Bajo wrote:
>> Blair Zajac <blair at orcaware.com> wrote:
>> 
>> 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.

I'm also -1 on turning it on by default because most of the time people
don't care about the bidirectional functionality, and any slow down due
to it will not be appreciated. But how about being able to turn it on by
default via an environment variable or a ~/.subversion/svnmerge.conf
file or either one, for people such as Blair and myself that use the
functionality often?

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

I may not understand your intent, but the problem with storing this
information outside the repository is that it needs to be put there
after the commit is done -- which is outside of the scope of svnmerge.
That is why I originally chose the dot-files implementation, which gives
you the commit $Revision$ for free.

In any case, I don't believe that a cache (external or dot-files) will
buy us that much. The reason is that when the merge is done, the
reflected revisions are memorized anyway, and so the only revisions to
be checked are the ones since the last merge. So, with the log --verbose
optimization this should only be an issue for projects with many commits
and a lot of changes to the root directory (which should be relatively
rare). I could be wrong on this though.

> Blair Zajac <blair at orcaware.com> wrote:
> 3) Rename to --bi-dir from --bidi.

I'm -1 on your change from --bidi to --bi-dir. The latter sounds like
some sort of bisexual tryst (not that bisexual tryst's are a bad thing)
:-)  Also, Google returns > 3.5M results for "bidirectional". It returns
70,900 results for "bi-dir bidirectional" and 200,000 results for "bidi
bidirectional" so in popular lexicon "bidi" seems to be more closely
associated with bidirectional than "bi-dir" is. Even so, how about a
compromise on --bidirectional?  Its long but no one can argue its confusing.

Cheers,
Raman