[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: mergeinfo not inherrited when I thought it should

From: Pieter-Jan Busschaert <pieterjan.busschaert_at_gmail.com>
Date: Thu, 4 Nov 2010 14:00:23 +0100


>> 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

$ 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,

Received on 2010-11-04 14:01:24 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.