On Tue, Jan 26, 2010 at 6:01 PM, Paul Burba <ptbu...@gmail.com> wrote: > On Mon, Jan 25, 2010 at 12:45 PM, Paul Burba <ptbu...@gmail.com> wrote: >> On Mon, Jan 25, 2010 at 9:32 AM, Julian Foad <julian.f...@wandisco.com> >> wrote: >>> After merging all changes from a branch into the WC, a second attempt of >>> the same merge brings in a different file. >>> >>> Full Details >>> >>> I tried a merge in a clean WC of the branch 1....@902803, using an >>> r902780M trunk build of svn. (I confirmed with an r902508 trunk build >>> that excludes the recent patch to add notifications when mergeinfo is >>> being recorded. The results are the same except lacking the extra >>> notifications.) >>> >>> [[[ >>> $ svn merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803 >>> --- Merging r891676 through r902803 into '.': >>> U subversion/tests/cmdline/externals_tests.py >>> U subversion/libsvn_client/commit_util.c >>> >>> $ svn merge ^/subversion/branches/1.6.x-r891672/@902803 >>> --- Merging r891676 through r902803 into '.': >>> U subversion/tests/cmdline/externals_tests.py >>> U subversion/libsvn_client/commit_util.c >>> --- Recording mergeinfo for merge of r891676 through r902803 into '.': >>> U . >>> >>> $ svn diff -N >>> >>> Property changes on: . >>> ___________________________________________________________________ >>> Modified: svn:mergeinfo >>> Merged /subversion/branches/1.6.x-r891672:r891677-902803 >>> ]]] >>> >>> So far, so good. >>> >>> Then I requested the same merge again in the same (now modified) WC, >>> expecting nothing further should happen, but I got: >>> >>> [[[ >>> $ svn merge --dry-run ^/subversion/branches/1.6.x-r891672/@902803 >>> U STATUS >>> >>> $ svn merge ^/subversion/branches/1.6.x-r891672/@902803 >>> U STATUS >>> --- Recording mergeinfo for merge of r891676 through r902803 into '.': >>> G . >>> >>> $ svn diff -N >>> >>> Property changes on: . >>> ___________________________________________________________________ >>> Modified: svn:mergeinfo >>> Merged /subversion/branches/1.6.x-r891672:r891677-902803 >>> Index: STATUS >>> =================================================================== >>> --- STATUS (revision 902803) >>> +++ STATUS (working copy) >>> @@ -114,15 +114,6 @@ >>> Votes: >>> +1: stsp, rhuijben >>> >>> - * r892050, 892085 >>> - Fix a reintegrate bug which can occur when the merge source has >>> mergeinfo >>> - that explicitly describes common history with the reintegrate target. >>> - Justification: >>> - Reintegrate merges may not work if the reintegrate source has self- >>> - referential mergeinfo that is also self-referential to the reintegrate >>> - target. This occured in our own repository, see >>> - http://svn.haxx.se/dev/archive-2009-12/0338.shtml. >>> - Votes: >>> +1: pburba, rhuijben >>> >>> * r891672 >>> @@ -185,8 +176,6 @@ >>> Justification: >>> APIs should do what they say they do. >>> Votes: >>> - +1: pburba >>> - >>> Veto-blocked changes: >>> ===================== >>> >>> ]]] >>> >>> Why is it merging STATUS now? >> >> Why indeed. I see similar problems with STATUS, though I actually get >> a conflict. >> >> C:\SVN\src-branch-1.6.x-2>svn merge >> ^^/subversion/branches/1.6.x-r891672/@902803 >> --- Merging r891676 through r902803 into '.': >> U subversion\tests\cmdline\externals_tests.py >> U subversion\libsvn_client\commit_util.c >> --- Recording mergeinfo for merge of r891676 through r902803 into '.': >> U . >> >> C:\SVN\src-branch-1.6.x-2>svn merge >> ^^/subversion/branches/1.6.x-r891672/@902803 >> Conflict discovered in 'C:/SVN/src-branch-1.6.x-2/STATUS'. >> Select: (p) postpone, (df) diff-full, (e) edit, >> (mc) mine-conflict, (tc) theirs-conflict, >> (s) show all options: p >> C STATUS >> G subversion\tests\cmdline\externals_tests.py >> G subversion\libsvn_client\commit_util.c >> --- Recording mergeinfo for merge of r891676 through r902803 into '.': >> G . >> Summary of conflicts: >> Text conflicts: 1 >> >> C:\SVN\src-branch-1.6.x-2> >> >> Doing a quick debug I saw that we are call >> merge.c:drive_merge_report_editor() in an inexplicable attempt to >> merge this diff... >> >> ^/subversion/branches/1....@875961 >> ^/subversion/branches/1.6.x-r891...@892189 >> >> ...Which prompted some cursing on my part. >> >> I'm not entirely sure what is wrong here, though I suspect part of the >> cause is that r892189 was a merge from trunk to the >> ^/subversion/branches/1.6.x-r891672 branch in which no mergeinfo >> changes were committed -- see >> http://svn.haxx.se/dev/archive-2010-01/0615.shtml. > > A quick update. I redid the merge of r892189 so the correct mergeinfo > was created (still no idea how this didn't happen the first time > around, but that investigation continues). Unfortunately the repeat > merge still incorrectly attempts to repeat the merge, despite the > local mergeinfo changes showing it has already been done, and results > in the odd conflict on STATUS. > > C:\SVN\src-branch-1.6.x-2>svn merge ^^/subversion/branches/1.6.x-r891672 > Conflict discovered in 'C:/SVN/src-branch-1.6.x-2/STATUS'. > Select: (p) postpone, (df) diff-full, (e) edit, > (mc) mine-conflict, (tc) theirs-conflict, > (s) show all options: p > C STATUS > G subversion\tests\cmdline\externals_tests.py > G subversion\libsvn_client\commit_util.c > --- Recording mergeinfo for merge of r891676 through r903475 into '.': > G . > Summary of conflicts: > Text conflicts: 1 > > C:\SVN\src-branch-1.6.x-2> > > continuing to look into this...
Hi Julian, Sorry for the delay, had been working on some other things. I fixed this in r908335 http://svn.apache.org/viewvc?view=revision&revision=908335. Paul
