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. 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.
REALLY FIXING THE PROBLEM:
Stopping all the WC-to-WC production of needless explicit mergeinfo
would go a longggg way to avoiding this, but that doesn't help those
(including us) with lots of historical subtree mergeinfo. More and
more I think that copy and move (all, not just WC-to-WC) should never
produce mergeinfo on the destination *unless* the source has it. It
can't be worse than what we deal with now...
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 01:10:54 CET