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