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.20201@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.
Received on 2010-07-08 12:23:42 CEST