Re: Proposal: don't modify any unrelated mergeinfos during 'svn merge'

> Ok, let's not get too caught up in the above. Returning to what Mark
> already said the question is can we get consensus on what you propose:

Just to be short. I propose the following:

1) Don't change subtree mergeinfo when a merge doesn't affect that subtree.

2) Disable default elision (since it's effectively useless as-is if #1
is implemented).

3) Continue to record mergeinfo on the merge target property if the
merge is a no-op.

4) Implement on-demand elision (maybe a subcommand of svnadmin, maybe
a new switch to merge, whatever that can be decided later).

It seems that #3 contradicts #1. But I can't find any serious
drawbacks with this approach.

In that case we have the following situation with performance issues:
> B) The more gaps in a merge target's mergeinfo for the merge source,
> the more editor drives we must make to complete the merge.

There will be no more gaps than with the current implementation.

> C) The more subtrees with explicit mergeinfo the merge target has,
> where those subtrees have differing mergeinfo for the merge source
> than the target, the more gaps we have.

Much more less mergeinfo will be generated. So there will be less
subtrees with explicit mergeinfo. And on-demand elision will be still
available for us.

> For the record I am +1 on all this and would be happy to get a branch
> started to do it.

It will be excellent to have a special branch for this. I think it
will be much more easier to discuss the working prototype.

--
Danil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org