On Fri, Nov 7, 2008 at 7:10 PM, Paul Burba <ptburba_at_gmail.com> wrote:
> Today in IRC:
>
> <lisppaste4> kfogel pasted "reintegration failure" at
> http://paste.lisp.org/display/69922
>
> [floss]:/home/kfogel/src/subversion>svn merge --reintegrate
> https://svn.collab.net/repos/svn/branches/issue-2843-dev
> subversion/libsvn_client/merge.c:7228: (apr_err=195016)
> svn: Reintegrate can only be used if the revisions previously merged
> from the reintegrate target to
> 'https://svn.collab.net/repos/svn/branches/issue-2843-dev' are the
> same, but there are differences:
> branches/issue-2843-dev
> /trunk:31358-34104
> branches/issue-2843-dev/notes/tree-conflicts/design-overview.txt
> /trunk/notes/tree-conflicts/design-overview.txt:31940-34104
> branches/issue-2843-dev/notes/tree-conflicts/requirements.txt
> /trunk/notes/tree-conflicts/requirements.txt:31940-34104
> branches/issue-2843-dev/tools/buildbot/slaves/win32-xp-VS2005
> /trunk/tools/buildbot/slaves/win32-xp-VS2005:33536-34104
> branches/issue-2843-dev/www/development.html
> /trunk/www/development.html:31940-34104
> branches/issue-2843-dev/www/issue-tracker.html
> /trunk/www/issue-tracker.html:31940-34104
> branches/issue-2843-dev/www/tasks.html
> /trunk/www/tasks.html:31940-34104
>
> <pburba> kfogel: looking...
> <pburba> kfogel: looking at logs for a sec, trying to figure out why
> the subtree mergeinfo on that branch differs from the root of the
> branch
> <kfogel> pburba: thnks
> <kfogel> pburba: it may be relevant that whenever I've done a merge
> from trunk to branch, there have been svn:mergeinfo propchanges on
> various random individual files/dirs, for reasons I grok not.
> <kfogel> You can see them in the commits of the merges.
> <hwright> kfogel: welcome to subtree mergeinfo on trunk
> <kfogel> hwright: thanks :-)
> <peterS> which doesn't actually mean any subtree merges were ever
> done, it just means someone did 'svn cp' or 'svn mv' at some point
> <kfogel> well, that's certainly the case with some of those trees. In
> fact I had some trouble with
> trunk/tools/buildbot/slaves/win32-xp-VS2005 earlier (it was a rename
> of a dir that had had spaces in its name), and had to merge it
> separately after failing to merge it in r33560.
> <kfogel> The separate merge was r34008.
> <kfogel> Thereafter, total merges from trunk worked fine (though they
> always set those "extra" properties).
> <kfogel> pburba: the above might be of interest
> <pburba> kfogel: Did you ever revert any of the mergeinfo changes
> before committing a synch-up from trunk?
> * pburba assumes not...
> <kfogel> pburba: I've never changed any properties between doing a
> merge and doing the commit.
> <kfogel> oh
> <kfogel> well, I have done "svn resolved foo" before committing
> sometimes, so that I could commit the conflict markers and then do the
> resolution in a separate rev.
> <kfogel> But that doesn't affect any properties, right?
> <pburba> kfogel: shouldn't no
> <pburba> kfogel: What version of svn did you use to do your latest
> synch merge in r34105?
> <kfogel> near-head trunk
> <kfogel> wait let me see
> <kfogel> pburba: yeah, almost r34105 installed right now
> <kfogel> not sure of exact version
> <kfogel> it might have been the branch version instead of trunk, but
> they're pretty sync'd up already, and the branch changes shouldn't
> affect this.
> <pburba> kfogel: no worries, just wanted to be sure it wasnt an earlier 1.5.x
> <kfogel> no, no way
> <pburba> ok, just getting some unlikely things out of the way
> <kfogel> pburba: I have to log off. I'll check email later, but if
> you figure it out and want to just do the merge, that's fine too.
> Otherwise I'll poke at this more when I'm next online tonight or
> tomorow.
> <kfogel> tomorrow
> <pburba> I'm 90% sure Ive got it figured out, Ill send a mail to dev
> with the details. Its easy to fix in your case
> <kfogel> AFAIK the branch is okay to merge, and should be merged;
> there may be a few minor TODOs left, but they should be done on trunk
> IMHO.
> <kfogel> oh!
> <kfogel> great
> <pburba> It will take longer to explain than to do, but it will be
> useful to explain as Im sure we and others will hit it again
> <pburba> But I need to eliminate my 10% doubt first :-)
>
> Karl,
>
> Here is what happened as best I can tell:
>
> A) In r31358 the issue-2843-dev branch was made back in May.
>
> B) The first synch with trunk was done in r31940 in July which added
> some new paths with explicit mergeinfo from trunk already on them:
>
> /branches/issue-2843-dev/notes/tree-conflicts/design-overview.txt
> /branches/issue-2843-dev/notes/tree-conflicts/requirements.txt
> /branches/issue-2843-dev/www/development.html
> /branches/issue-2843-dev/www/issue-tracker.html
> /branches/issue-2843-dev/www/tasks.html
>
> C) Later in r34008 a third synch merge was done which added this file
> with explicit mergeinfo from trunk already on it:
>
> /branches/issue-2843-dev/tools/buildbot/slaves/win32-xp-VS2005
>
> Now since r32975 when a merge adds explicit mergeinfo to an existing
> subtree that had no explicit mergeinfo prior to the merge, the subtree
> gets any mergeinfo it inherited prior to merge made explicit and this
> is combined with the incoming mergeinfo from the source - see
> http://subversion.tigris.org/servlets/ReadMsg?listName=dev&msgNo=142460.
> *But* we don't do this for paths which are added with mergeinfo, and
> I'm not sure it makes any sense to do so either (though it would help
> in this situation). I hadn't forseen that this would be a common
> scenario that would prevent reintegrate, but I don't see how we can
> prevent it. Anyway, let's continue on in case it's not obvious what
> went wrong with this particular example.
>
> D) So the six paths in B and C have explicit mergeinfo. On the
> subsequent synch merges from trunk in r34009, r34015, r34098, r34012,
> and r34105 if no revision range is specified the merge logic looks at
> the mergeinfo on the target, i.e. the root of your issue-2843-dev WC,
> to determine what ranges to try to merge. Since the mergeinfo on the
> root "says" that everything from trunk_at_31358 through trunk@(rev of the
> last synch merge - 1) has been merged from trunk, then that is all the
> merge attempts to do. It doesn't consider the subtrees mergeinfo.
>
> E) But when you try to reintegrate the issue-2843-dev branch back to
> trunk we *do* care about that subtree mergeinfo. We don't want to
> perform reintegrate's underlying 2-URL merge if we haven't kept the
> branch synched up with trunk. And as far as reintegrate can tell we
> haven't, it looks like trunk r31357:34104 was not uniformly merged
> from trunk to issue-2843-dev because of the mergeinfo on the paths in
> B and C.
>
> I hope that all makes some sense. So what to do then?
>
> THE IMMEDIATE SOLUTION:
>
> We need to make the subtree mergeinfo on the branch look like
> r31357:34104 has been uniformly merged from trunk, so we can do a
> --record-only merge:
>
> C:\SVN\issue-2843-dev>svn merge http://svn.collab.net/repos/svn/trunk
> . -r31357:34104 --record-only
>
> Only the mergeinfo changes:
>
> C:\SVN\issue-2843-dev>svn st
> M www\issue-tracker.html
> M www\development.html
> M www\tasks.html
> M notes\tree-conflicts\requirements.txt
> M notes\tree-conflicts\design-overview.txt
> M subversion\tests\cmdline\tree_conflict_tests.txt
> M subversion\include\private\svn_cache.h
> M tools\buildbot\slaves\win32-xp-VS2005
>
> I made this change in r34107...
>
> ...Unfortunately it isn't sufficient:
>
> C:\SVN\src-trunk-2>svn merge --reintegrate
> http://svn.collab.net/repos/svn/branches/issue-2843-dev .
> ..\..\..\subversion\libsvn_client\merge.c:7311: (apr_err=195016)
> svn: Reintegrate can only be used if the revisions previously merged
> from the reintegrate target to
> 'http://svn.collab.net/repos/svn/branches/issue-2843-dev' are the
> same, but ther
> e are differences:
> branches/issue-2843-dev
> /trunk:31358-34104
> branches/issue-2843-dev/notes/tree-conflicts/design-overview.txt
> /trunk/notes/tree-conflicts/design-overview.txt:31389-34104
> branches/issue-2843-dev/notes/tree-conflicts/requirements.txt
> /trunk/notes/tree-conflicts/requirements.txt:31389-34104
> branches/issue-2843-dev/subversion/include/private/svn_cache.h
> /trunk/subversion/include/private/svn_cache.h:33828-34104
> branches/issue-2843-dev/subversion/tests/cmdline/tree_conflict_tests.txt
> /trunk/subversion/tests/cmdline/tree_conflict_tests.txt:33082-34104
> branches/issue-2843-dev/tools/buildbot/slaves/win32-xp-VS2005
> /trunk/tools/buildbot/slaves/win32-xp-VS2005:33536-34104
> branches/issue-2843-dev/www/development.html
> /trunk/www/development.html:31663-34104
> branches/issue-2843-dev/www/issue-tracker.html
> /trunk/www/issue-tracker.html:31663-34104
> branches/issue-2843-dev/www/tasks.html
> /trunk/www/tasks.html:31665-34104
>
> ...since the reintegrate code is comparing natural history converted
> to mergeinfo with explict mergeinfo. The latter might contain some
> bogus path/revisions, see
> http://subversion.tigris.org/issues/show_bug.cgi?id=3157#desc8, which
> is the case here. I'm looking at a minor tweak that would fix this
> right now.
Karl,
This is not going to be as simple as I hoped.
> In the meantime, while it pains me to say it, but if you
> really want to get this merged back to trunk ASAP you'll have to use a
> 2-URL merge.
I gotta call it a night so I merged it back via a 2-URL merge in r34108.
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-11-08 04:17:27 CET