Hi, The computation of the last modification revision (as in the expansion of the $Rev$ keyword or the second column of the output of "svn status -v") seems to depend on the update path of the working copy used, rather than only on the history of the file in the repo. It looks wrong to me, and after asking on the user list [1] I didn't get any convincing explanation of this behaviour, so I'd like to have your opinion: is this a bug or do I just fail to understand why it is to be expected?
http://mail-archives.apache.org/mod_mbox/subversion-users/201006.mbox/%3c4c124388.20...@elzevir.fr%3e The problem happens when you do a svn copy of a directory. Afterwards, the "last revision" of files in this directory (no modified after the cp) is computed differently in the working copy where the cp operation was made than in any other working copy. Running svn up in the incriminated wc doesn't change anything, but svn up'ing to an earlier revision, then back to the last revision does. Here is a reproducer. svnadmin create repo svn co file://$PWD/repo active svn co file://$PWD/repo passive cd active svn mkdir dir touch dir/file svn add dir/file svn ci -minitial svn cp dir newdir svn ci -m'after cp' cd .. cp -a active active-back-then-up (cd passive && svn up) (cd active && svn up) (cd active-back-then-up && svn up -r1 && svn up) svn status -v */newdir/file The output of the final svn status -v looks as follows: 2 1 mpg active-back-then-up/newdir/file 2 2 mpg active/newdir/file 2 1 mpg passive/newdir/file As you can see, only the "active" repo thinks newdir/file's last modification is at revision 2, other repositories compute it as 1. Thanks in advance for your comments, Manuel.
