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

[Raman Gupta]

Blair Zajac wrote:
> Raman Gupta wrote:
>> 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.

Yup, perfect.

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

Exactly.

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

Hmmm, I don't like it simply because there is no guarantee the user will
actually run svnmerge.py commit instead of svn commit.  I can easily see
even myself screwing up just because my brain is so used to typing "svn
commit".  Although I guess in this case svnmerge will fall back to
running the diff on the revision and noticing that it is reflected.

I still don't like it though -- seems too brittle -- for example, how do
you handle branch renames with this external cache? We would have to
grow another option to svnmerge. I think if we are going to cache this
information, it should be stored with the branch in dot-files, using the
$Revision$ keyword as per my original implementation (and of course,
this dot-file caching should be optional). Although, now that I think
about it, the dot-file approach will break if a branch is renamed too,
but it at least doesn't require separate actions during or after commit
time.

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

Good.

Cheers,
Raman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3448 bytes
Desc: S/MIME Cryptographic Signature
Url : /pipermail/svnmerge/attachments/20060222/fe127893/attachment.bin