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):
/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
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':
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.
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.
Paul
---------------------------------------------------------------------
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