On 2012-07-03 13:15:33 +0200, Johan Corveleyn wrote: > No, it's not the same issue (the issue you reported is, let's say, > open for discussion, and I don't think the 1.7 behavior is wrong ... > it's just different from 1.6).
OK, I actually focused on "svn info .../subdir", where you get "Last Changed Rev: 2" with svn 1.7.5 while with svn 1.6.x, one would have got 3 (because the subdir parent moved at rev 3), and this corresponded to what I reported. Now in your case, you also modify test.txt in subdir. After some tests, it seems that the LastChanged* metadata of a directory are updated whenever something has changed below the directory (except in particular cases as you reported). This is something I didn't notice before, even though it is the same behavior as with 1.6.x. So, according to this behavior, one would expect 3. I would say that the main problem is that the LastChanged* metadata are underspecified. The Subversion book doesn't seem to specify anything except for keyword substitution, where it says: This keyword describes the last known revision in which this file changed in the repository, and looks something like $Revision: 144 $. It may also be specified as LastChangedRevision or Rev. But a change of the contents of a file isn't a change of the directory that contains it (neither of any of its ancestors). So, the current behavior of "svn info" on directories would be incorrect in most cases. > The issue I'm reporting in this thread is that the LastChangedRev > differs between 'svn info subdir' and 'svn info > url-of-subdir@workingrev-of-subdir'. That seems wrong, it means that > the working copy (from where the move was committed) has a > LastChangedRev that's different from the repository and from any other > working copy that's checked out (from that same working revision). Actually I would say that "svn info subdir" is correct, and all the other cases are incorrect. > Note that this is only the LastChangedRev of the intermediate subdir > which I'm talking about, so I don't think there's an impact on Keyword > Substitution. Yes, the issue is specific to directories, for which there are no possible keyword substitutions. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <http://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
