On Thu, Nov 4, 2010 at 2:00 PM, Pieter-Jan Busschaert
<pieterjan.busschaert_at_gmail.com> wrote:
> 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.
Ok, maybe this is not that extremely rare (however, this is the first
report I see about this on the users list, so it's not that common
either).
> 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
Yes it does. It changes the working revision of branch/subdir from 3
to 5. Since this update didn't bring in new explicit mergeinfo on
branch/subdir, svn can now safely assume that the mergeinfo from
/branch can be inherited (before this update, it could not be sure
about that).
> $ 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 ???
Hm, maybe that's because it can now inherit the mergeinfo from
/branch, which was introduced in r5. So in effect, this branch/subdir
*was* changed in r5, namely it inherits new mergeinfo from branch.
> 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.
Indeed, the second column is only information present in the working
copy (it doesn't contact the repository to see that the last changed
rev over there is higher than what it has in the working copy).
> 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.
Why? Because it's new technology, a rewrite of some piece that has
already 10 years of maturity (and numerous bugfixes and optimizations)
under its belt? And they fear a lot of instability because of this?
If so, I can certainly understand this argument. New stuff introduces
new bugs, and it will all be brand new, so ... However, WC-1 was
really at the end of its powers. Some problems (and the number of them
was steadily increasing) were really becoming extremely difficult to
solve. The rewrite was/is absolutely necessary to go forward. It will
help fix a lot of problems (like this one), and open up possibilities
for much more interesting features in the future (like offline
commits, checkpointing, better tree conflict handling, better tracking
of renames, better merge tracking, ... a lot of these things depend on
WC-NG).
The only thing I can say is: please help making the 1.7 release as
stable/bugfree as possible, by testing it as soon as you can. Most of
the stuff is working-copy related, so you can easily set up a
throw-away working copy to test some things in your company.
If I understood correctly, the developers will work together with some
of the binary distributors to set up a beta program, where betas and
release candidates will be distributed as compiled binaries for
various platforms, to get as much test coverage as possible before the
release. So, if those betas start appearing: please help testing them,
and report bugs as soon as you can.
Cheers,
--
Johan
Received on 2010-11-05 11:33:16 CET