[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: Fri, 5 Nov 2010 13:07:07 +0100

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

Received on 2010-11-05 13:08:07 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.