Hello, >> There are a few things still not clear to me: >> 1) Before this svn update, svn stat -u shows nothing out-of-date, so >> it's strange that an update makes any difference. > > Try "svn stat -v", and you'll see the different working revisions of > the files and dirs in the working copy. It's the out-of-date working > revision that is actually causing this. Updating it brings it all at > the same level, so svn can be sure that it has consistent information.
Yes, I noticed that. I had put the output of svn stat -v in the reproduction scenario. I am not really certain why you say "so svn can be sure it has consistent information". I always thought if my working revision was >= last changed revision, then I had everything up-to-date. [however, see below] >> 3) If I check the relevant svn:mergeinfo properties before / after >> this svn update, I see no changes at all. However, if I check with the >> svn mergeinfo command, then I do see a change after the update. What >> else is being used to calculate the actual mergeinfo? > > You should really read the entire section "Mixed Revision Working > Copies and Mergeinfo" of the article > http://www.collab.net/community/subversion/articles/merge-info.html. I > think the example near the end of that section describes a very > similar situation. I think you are seeing exactly the same thing here. OK, that was an interesting section to read. However, from my experience, the sentence "Admittedly both of these example are a bit contrived, and you may never run into anything like them." is a bit far-fetched. Without the rule to only merge on top-level, you run into this frequently. Now, I have been able to narrow down the necessary svn update a bit further. Same reproduction script as before, just before the "bad" second merge. r5 is the first merge which: (1) updated the file /branch/subdir/test.txt and (2) added mergeinfo on /branch. $ svn stat -u -v 6 6 pjbu trunk/subdir/test.txt 3 2 pjbu trunk/subdir 3 2 pjbu trunk 5 5 pjbu branch/subdir/test.txt 3 2 pjbu branch/subdir <=== this causes the wrong mergeinfo 5 5 pjbu branch 3 3 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r4 <=== was already merged, it is in svn:mergeinfo on /branch @ r5 r6 $ svn up -r 5 --depth=empty branch/subdir At revision 5. <====== doesn't change anything $ svn stat -u -v 6 6 pjbu trunk/subdir/test.txt 3 2 pjbu trunk/subdir 3 2 pjbu trunk 5 5 pjbu branch/subdir <=== the last-commited rev in the repo also changed ??? 5 5 pjbu branch/subdir/test.txt 5 5 pjbu branch 3 3 pjbu . Status against revision: 6 $ svn mergeinfo --show-revs eligible $REPO/trunk/subdir branch/subdir r6 <==== correct now Well, I can see how svn has trouble when merging into branch/subdir without that directory itself being atleast at the revision where the mergeinfo was added to its parent. However, there seems something strange with the notion of out-of-date on a directory. I thought the second column of revision numbers in svn stat -v was completely independent of the working copy status, but that doesn't seem to be the case. It's a pity all the improvements around tracking mergeinfo will only be included in 1.7, because I fear all the WC-NG developments will make our company even more reluctant to update to that version. Thanks for the help, Pieter-Jan
