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