[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: Wed, 17 Sep 2008 08:41:19 -0400

On Wed, Sep 17, 2008 at 8:13 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> 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.

...and I hope it is straightforward. I'm sure there will be some
complications...there always are with merge tracking.

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

I'll start work on a branch for this sometime this week if no
objections come up.

>> * 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? :)

I think we should keep elision, but not have it happen automatically
but rather upon request. Rather than going into it too much here just
see this thread: http://svn.haxx.se/dev/archive-2008-09/0595.shtml


>> > 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:41:34 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.