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

[Alan Barrett]

> >> I'm also -1 on turning it on by default because most of the time
> >> people don't care about the bidirectional functionality,

I question that assumption.

With release branches, people usually merge in only one direction (from
the trunk to the release branch).  But with feature branches, in my
experience, people almost always merge in both directions: several
merges from the trunk to the feature branch during development of the
feature; once from the feature branch to the trunk just before the
branch is abandoned; and possibly a few more times from the branch to
the trunk if it makes sense to provide work in progress snapshots to the
trunk.  I sometimes use parallel branches where changes are merged back
and forth all the time.

> >> and any slow down due to it will not be appreciated.

Yes, I agree with that.  So I'd like the merge to work properly
(bidirectional) in the default case, with an option for the unsafe but
faster (unidirectional) method.

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

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

--apb (Alan Barrett)