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

[Blair Zajac]

Raman Gupta wrote:
> 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?

Sounds good.  I like the ~/.subversion/svnmerge.conf idea.  I'd also like it to 
look for an /etc/subversion/svnmerge.conf file so if you package an RPM or a 
deb, you can set it system wide.

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

We agreed that having svnmerge.py require any additional commits beyond the 'svn 
commit' to commit the merge would not work.  However, this wouldn't prevent a 
secondary, external cache to help improve performance.

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

After you get the list of revisions using the log --verbose optimization, you 
can look in the cache and see if any of those commits were done by previous 
svnmerge.py's, so you can remove them from list of revisions to check for 
reflected merges.

But even this cache is subject to breakage if they run svnmerge.py but don't go 
through with the commit, the cache would not reflect what really happened.

Maybe we should introduce an svnmerge 'commit' command to take care of any 
follow up work to do.  It would be good for consistency, as currently, we use 
svnmerge.py to do everything but the commit, which is odd for consistency.

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

Agreed.  And we have -b for the shortcut.

Regards,
Blair