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

Re: Mergeinfo for skipped paths? (was: Re: Tree Conflicts and User Interface)

From: Paul Burba <ptburba_at_gmail.com>
Date: Tue, 16 Sep 2008 20:22:51 -0400

2008/9/15 Stefan Sperling <stsp_at_elego.de>:
> On Fri, Sep 12, 2008 at 02:34:32PM +0200, Stefan Sperling wrote:
>> On Fri, Sep 12, 2008 at 01:57:53PM +0200, Stefan Sperling wrote:
>> > There are certain types of conflicts that require an additional
>> > merge to be resolved, such as when a textdelta is applied to a file
>> > which is not yet present in the target branch -- the fix is to
>> > *repeat* the merge with a wider revision range, this time including
>> > the revision in which the file was created on the source branch.
>> I just realised that this is wrong.
>> The merge cannot simply be repeated.
>> Because of merge tracking, the file addition would be merged,
>> but the textdelta would not be merged again.
>> So the final merge result would miss the textdelta,
>> unless the user reapplied it manually.
> On second thought, this is actually a problem with the way
> we're currently recording mergeinfo. It cannot account
> for failed merges due to missing paths.
> Say there was a textdelta for file foo.c in revision 4,
> and the file foo.c was created in revision 3.
> I am merging revision 4 into a branch.
> In the current implementation, revision 4 (the textdelta)
> will be skipped, but mergeinfo will claim that revision 4
> was merged! (See attached recipe script for reference.)
> /trunk:2,4
> Instead, I'd expect explicit mergeinfo on foo.c with
> revision 4 omitted:
> /trunk/foo.c:2
> or even:
> /trunk/foo.c:2,!4
> if such "negative mergeinfo" was feasible -- it may be easier
> to record "We failed to apply revision X to path Y" rather
> than determining the answer to the question "Which revisions
> in the merge range could not be applied to path Y?" after
> a merge of some arbitrary revision range.
> A problem of course is that we can't create create mergeinfo
> for foo.c if it does not yet exist in the branch's working copy :(
> So before we can solve this problem, we'd probably need to store
> mergeinfo somewhere else than properties...
> Any idea on how we could record mergeinfo for skipped paths
> in the current implementation?

Hi Stefan,

Let's assume your target branch looks like this (these other paths
under trunk help better illustrate what I'm going to propose):


We tweak the merge logic to set non-inheritable mergeinfo on the merge
target describing the merge, and normal mergeinfo on all the target's
present children, like this:

Properties on 'branch':
    /trunk:2,4* <--- Non-inheritable mergeinfo.
Properties on 'branch/bar.c':
Properties on 'branch/subdir':

Of course if the skipped path was a deeper subtree and not an
immediate child of our merge target we would adjust accordingly and
set the non-inheritable mergeinfo on the skipped path's immediate
parent and the normal mergeinfo on the skipped path's siblings.

If we commit the above merge and then merge -c3 into branch now foo.c
is added but it only has mergeinfo for r2-3:

Properties on 'branch':
Properties on 'branch/foo.c':
Properties on 'branch/bar.c':
Properties on 'branch/subdir':

Note: In my ad hoc testing foo.c isn't getting r2 in it's mergeinfo,
it should, but that can be fixed. Assuming that we fix this, if we
re-merge -r4 to branch then foo.c gets that change and all the
mergeinfo elides* up to branch and we are left with is this:

Properties on 'branch':

I think this change is fairly simple, we already catch similar cases -
see libsvn_client/merge.c:get_mergeinfo_paths(). The only difference
is that we can't identify these paths at the start of the merge but
must catch them once we realize they are skipped. The
notification_receiver_baton_t struct keeps track of these already in
its skipped_paths member so this shouldn't be too hard.

I can crank out a patch that does what I propose in fairly short order
if this idea solves your problem.

* In the interests of full disclosure, in another thread I am
proposing the elimination of automatic mergeinfo elision as a fairly
useless feature...ironically here is a case where it is nice to have

> XXX big ugly hack idea: Could we extend the mergeinfo
> format so that parent directories can record "negative"
> mergeinfo for direct children which were skipped?

Befitting a "big ugly hack" there's a problem :-) What if, in your
example, r4 also affected trunk directly (e.g. we added a svn:ignore
property). It could get a bit ugly if we want a way to record that r4
affected trunk, but not one of its (currently) non-existent children.


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-17 02:23:06 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.