> On Sat, Sep 10, 2011 at 03:43:36AM +0200, Stefan Sperling wrote:
> > It seems that the elision algorithm is very basic at the moment, which
> > prevents this from being really useful. Subversion only elides
> > mergeinfo which exactly matches the mergeinfo of a parent.
> > It doesn't perform elision if mergeinfo on the parent covers a greater
> > range of revisions than the mergeinfo on the child.
> >
> > Is this deliberate?
> >
> > For instance:
> >
> > r3 changed '/branch/gamma'.
> > This is merged into '/trunk', as follows:
> >
> > $ svn merge --reintegrate ^/branch/gamma gamma
> > --- Merging differences between repository URLs into 'gamma':
> > U gamma/delta
> > --- Recording mergeinfo for merge between repository URLs into 'gamma':
> > U gamma
> > $
> >
> > Nothing further happens on the branch.
> > Later, we merge the entire branch (a no-op merge):
> >
> > $ svn merge --reintegrate ^/branch
> > --- Recording mergeinfo for merge between repository URLs into '.':
> > U .
> > $
> >
> > Note that no elision took place.
> > Now we have the following mergeinfo which will not elide:
> >
> > Properties on '.':
> > svn:mergeinfo
> > /branch:2-4
> > Properties on 'gamma':
> > svn:mergeinfo
> > /branch:2-3
> >
> > The following mergeinfo will elide:
> >
> > Properties on '.':
> > svn:mergeinfo
> > /branch:2-4
> > Properties on 'gamma':
> > svn:mergeinfo
> > /branch:2-4
> >
> > So the user is required to run no-op merges on subtrees in order to
> > elide mergeinfo from subtrees. This can be quite tedious.
>
> The updated patch below allows mergeinfo to elide if the child mergeinfo is a
> subset of the mergeinfo inherited from a parent.
>
> This seems to work fine in ad-hoc testing.
> There are some test failures with this patch, but before looking into fixing
> those I'd like to ask merge-tracking gurus if I am being naive and overlooking
> some obvious problem?
>
> I would commit this change in two steps. One that elides mergeinfo more
> aggressively, and one for the mergeinfo --elide parts.
> However, this combined patch is more useful for testing and review.
My question would be will this only elide merge info from child nodes that have been modified by the merge in the same way that in 1.7 child node merge info is only updated if that child node was a target of the merge?
I don't think you want to re-introduce the problem of mergeinfo being modified on child nodes that the merge didn't affect after making the enhancement to merge in 1.7.
BOb
Received on 2011-09-13 17:16:16 CEST