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

Re: now with more agressive elision (was: [PATCH] svn mergeinfo --elide)

From: Stefan Sperling <stsp_at_elego.de>
Date: Sat, 10 Sep 2011 22:05:19 +0200

On Sat, Sep 10, 2011 at 02:08:38PM -0400, Paul Burba wrote:
> Given:
>
> A path P and some path-wise child of P called C:
> Assume both P and C have explicit mergeinfo.
> Assume there is no intermediate patch between P and C with explicit mergeinfo.
> Assume P and C are at the same revision as are any intermediate
> paths between them.
>

Ah, right. I didn't think at all about mixed-revisions...

> Question:
>
> Can the mergeinfo on C elide to P?
>
> Looking at the intersection of the P and C's mergeinfo we have:
>
> A) Common mergeinfo (that differs only by the path-wise difference
> between P and C) - This can elide.
>
> B) Mergeinfo exclusive to P - If *all* of this describes merges that
> are inoperative on C, then this can elide.
>
> C) Mergeinfo exclusive to C - If all of this describes merges that are
> operative only on C and/or on subtrees which are not part of P, then
> this can elide.
>
> If elision occurs in *all* three cases then the mergeinfo on C can elide to P.

Nice. We should try to implement that.

> > Do you think there is value in adding just 'svn mergeinfo --elide'
> > and keep using the present elision code?
>
> Yes, I think the basic idea is sound: Some way to trigger the elision
> code outside of a merge proper. Admittedly today it has rather
> limited usefulness, but only because elision itself is so "dumb".
> Once elision gets smarter it will be more useful. But there's no
> reason no to add it now.

Ok, I'll add the --elide option so. Thanks Paul!
Received on 2011-09-10 22:06:01 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.