[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 23 Sep 2008 12:00:23 -0400

On Tue, Sep 23, 2008 at 11:11 AM, Danil Shopyrin <danil_at_visualsvn.com> wrote:
>> 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.

Hi Danil,

Just a quick note, I'm not ignoring this thread, it's just that I'm up
to my eyeballs working on merge algorithm bug related to subtrees. As
soon as I'm done with that then *this* thread is my next priority.

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-09-23 18:00:43 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.