>> $ 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).
OK. But if svn merge already contacts the repository when it doesn't
find any mergeinfo in the WC, then I think it could contact the
repository to automatically check for the above case too.
>> 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).
Thanks for the clarification, I thought the combination of -u and -v
would show me the state in the repository, but this is clearly not the
case. I also noticed directories get the highest last-changed
rev-number of any of their children, even if nothing really changed on
the directory properties itself. These 2 things got me confused...
>> 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.
>
> The rewrite was/is absolutely necessary to go forward.
I know and I will try to keep some of these testcases around to check with 1.7.
Kind regards,
Pieter-Jan
Received on 2010-11-05 13:08:07 CET