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

[Raman Gupta]

Alan Barrett wrote:
>>> Maybe we should introduce an svnmerge 'commit' command to take care of
>>> any follow up work to do.
>> 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 agree.
> 
> However, a "svnmerge.py merge-and-commit" command might make sense,
> possibly with an option to invoke an editor on the log message.

No way -- I, and I am presuming others, always want to review the
results of merges in a diff tool for example, before the commit. In
addition, this breaks if there are any conflicts.

>> 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.
> 
> I really dislike the idea of storing merge metadata anywhere that would
> make the result of "svn export" unclean.  Store it in a cache in the
> WC, or in a property in the repository, but please not in a file in the
> repository.

Its true the dot-files implementation is a little messy, but in terms of
performance optimization you can't beat it because it gives you all of
the merge revisions up to and including the current one (because of the
$Revision$ property). So finding reflected revisions is always one
operation. However, the "unsightliness" of it is why I suggested it
would be optional, and only turned on in cases where the performance
optimization was necessary.  All in all though, I agree with you -- I
would rather not use them either.

I do like the idea you suggested in a previous email of storing the
*previous* merge revisions in a property, but that approach will still
be slow in cases where there are a lot of commits between merges.

Cheers,
Raman