Paul Burba wrote on 2012-04-23:
>>> Do you have a pointer to some details about how a mixed-rev target WC
>>> is handled?
>
> (Julian, apologies if most of this is old-hat for you, I'm writing as
> much for the newly involved folks as I am for you)
Hi Paul. Thanks for this detailed exposition.
> At the most basic level, mixed-revision WCs impact how mergeinfo is
> (or isn't) inherited[1]. The best place to start is looking at the
> doc string for svn_client__get_wc_mergeinfo. Essentially, within the
> working copy, a CHILD path without explicit mergeinfo may inherit[2]
> mergeinfo from its working copy PARENT if:
[...]
> ### Still have that mixed-rev WC:
>
>> svn st -v
> 8 8 pburba .
> 7 1 jrandom mu
[...]
> 7 1 jrandom D
> 7 1 jrandom D\H
> 9 9 pburba D\H\psi
>
> ### A repeat of the cherry pick to the root of our branch (where the
> ### explicit mergeinfo is found) is a no-op:
>
>> svn merge ^^/A . -c4 --allow-mixed-revisions
> --- Recording mergeinfo for merge of r4 into '.':
> U .
>
> ### But if we perform a subtree merge to 'D', the target doesn't
> ### inherit the explicit mergeinfo on '.' because of the mixed-rev
> ### inheritance rules, so the repository is contacted to see what
> ### mergeinfo D_at_7 inherits (which is none). The fact that a subtree
> ### of the target, D/H/psi *does* inherit mergeinfo reflecting the
> ### previous cherry-pick is not considered, so the merge is
> ### repeated, producing a spurious text conflict:
>
>> svn merge ^^/A/D D -c4 --allow-mixed-revisions
> Conflict discovered in '[...]D/H/psi'.
So this is a case where we know how it should work, semantically, but it's not currently implemented.
> Situations similar to this are what lead us to disallow merges to
> mixed-rev working copies by default (i.e. adoption of the
> --allow-mixed-revisions option
> http://svn.haxx.se/dev/archive-2010-10/0000.shtml).
>
> Certainly it would be possible to detect cases like this, but doing so
> in a performant manner is another question.
OK, thanks; it's good to know what we're dealing with here.
- Julian
Received on 2012-04-24 16:55:12 CEST