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

Re: Incorrect handling of svn:mergeinfo during merging on the svnpatch-diff branch

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 11 Sep 2008 16:03:50 +0100

On Thu, 2008-09-11 at 13:51 +0100, Julian Foad wrote:
> On Wed, 2008-09-10 at 11:40 -0400, Paul Burba wrote:
> > On Tue, Sep 9, 2008 at 4:32 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> > > Now for the specifics: What's going wrong here is that when we perform
> > > the reverse merge of -c-32625,
> > > libsvn_subr/merge.c:filter_self_referential_mergeinfo() is filtering
> > > out /trunk:1-31375' portion of svnpatch-diff's mergeinfo. As
> > > mentioned above it should only filter out '/trunk:1-28961', so that is
> > > one bug. But I can't see any reason to ever do filtering of this type
> > > during a *reverse* merge. Currently the svn_wc_diff_callbacks3_t
> > > callback merge.c:merge_props_changed() calls
> > > filter_self_referential_mergeinfo() without consideration of the
> > > merge's direction.
> > >
> > > So we need to do the following:
> > >
> > > 1) Stop filtering self-referential mergeinfo during reverse merges
> > > (easier said than done as we don't have enough context in the callback
> > > to determine merge direction right now). If you or anything else can
> > > see a reason this filtering needs to be done in reverse merges please
> > > let me know!
>
> This looks OK, but I struggled to fully understand both the motivation
> and the correctness.

Paul explained to me on IRC...

> Note that the "filtering", although currently implemented as a single
> function call, is performing two different logical functions:
>
> 1. Avoid adding any self-referential mergeinfo in the current merge.
> 2. Clean up any self-referential mergeinfo that may have existed.

I was completely wrong about that. It only does (1), and (1) is what's
under discussion. That means it makes sense to avoid calling this
filtering function in a reverse merge. It still should not matter if we
did call it, except there is currently a bug in it.

Sorry for the confusion.

Paul is following up with more details.

- Julian

---------------------------------------------------------------------
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-11 17:04:12 CEST

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