[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: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 17 Sep 2008 14:13:40 +0200

On Tue, Sep 16, 2008 at 08:22:51PM -0400, Paul Burba wrote:
> 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):
>
> /branch
> /branch/bar.c
> /branch/subdir
>
> 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':
> svn:mergeinfo
> /trunk:2,4* <--- Non-inheritable mergeinfo.
> Properties on 'branch/bar.c':
> svn:mergeinfo
> /trunk/bar.c:2,4
> Properties on 'branch/subdir':
> svn:mergeinfo
> /trunk/subdir:2,4

Sounds like a plan!

> 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.

Yes.

> 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':
> svn:mergeinfo
> /trunk:2-3,4*
> Properties on 'branch/foo.c':
> svn:mergeinfo
> /trunk/foo.c:2-3
> Properties on 'branch/bar.c':
> svn:mergeinfo
> /trunk/bar.c:2-4
> Properties on 'branch/subdir':
> svn:mergeinfo
> /trunk/subdir:2-4
>
> 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':
> svn:mergeinfo
> /trunk:2-4
>
> 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.

It's nice to know that you have a simple solution.
I was afraid of the solution being really complicated,
but your proposal sounds very straightforward.

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

Great. I'll gladly test anything you throw at me.

> * 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
> :-\

So we keep it? :)

> > 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.

Oh, I was thinking about extending the mergeinfo format to include
names for skipped child paths, something like

 Properties on 'branch':
   svn:mergeinfo
     /trunk:2-4,foo.c:!3
                ^^^^^
But your solution is much better, so let's forget about this :)

Thanks!
Stefan

---------------------------------------------------------------------
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 14:14: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.