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
Received on 2010-11-04 14:01:24 CET