Your message dated Tue, 19 Jun 2012 01:41:29 -0500
with message-id <20120619064129.gq...@p12n.org>
and subject line Re: Bug#678075: subversion: incorrect Last Changed Rev after
upgrade from 1.6.17 to 1.7.5
has caused the Debian Bug report #678075,
regarding subversion: incorrect Last Changed Rev after upgrade from 1.6.17 to
1.7.5
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
678075: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678075
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: subversion
Version: 1.7.5-1
Severity: grave
Justification: causes non-serious data loss
(actually that's silent data corruption in the WC)
Subversion 1.7.5 no longer notices a change of revision of some file
when a parent directory has been moved. In particular, this yields
incorrect keyword expansion.
The bug can be reproduced with the following script:
------------------------------------------------------------
#!/bin/sh
set -e
mkdir my-test-svn
cd my-test-svn
svnadmin create svn
svn co file://`pwd`/svn wc
cd wc
svn mkdir dir1
svn ci -m 'add dir1'
printf '\044Revision\044\nfoo\n' > dir1/file
svn add dir1/file
svn propset svn:keywords Revision dir1/file
svn ci -m 'add dir1/file'
echo "File dir1/file:"
cat dir1/file
svn up
svn mv dir1 dir2
echo "File dir2/file:"
cat dir2/file
svn ci -m 'mv dir1 dir2'
echo "File dir2/file:"
cat dir2/file
svn up
echo "File dir2/file:"
cat dir2/file
svn info dir2/file
svn mv dir2/file .
echo "File file:"
cat file
svn ci -m 'mv dir2/file .'
echo "File file:"
cat file
cd ../..
rm -rf my-test-svn
------------------------------------------------------------
If I grep the output with '.Revision:\|Last Changed Rev:', I get:
* svn 1.6.17 (r1128011): 2 2 3 3 3 -1 4
* svn 1.7.5 (r1336830): 2 2 2 2 2 2 4
There are 4 differences, but only 3 really matter, because for the
last one (-1 vs 2), the commit hasn't been done yet (so that one is
in some intermediate state).
Thus the important differences (3 vs 2) correspond to:
svn ci -m 'mv dir1 dir2'
echo "File dir2/file:"
cat dir2/file
svn up
echo "File dir2/file:"
cat dir2/file
svn info dir2/file
The last test of the script shows that the problem doesn't occur
when the file itself is moved.
Because of that, when checking out a repository with svn 1.7.5, some
files seem to go back in time.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages subversion depends on:
ii libapr1 1.4.5-1.1
ii libc6 2.13-33
ii libsasl2-2 2.1.25.dfsg1-4+b1
ii libsvn1 1.7.5-1
subversion recommends no packages.
Versions of packages subversion suggests:
pn db5.1-util <none>
ii patch 2.6.1-3
ii subversion-tools 1.7.5-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Vincent,
Thanks for the very detailed bug report. I'm closing it, though,
because I think you are misinterpreting, and the 1.7 behavior is
actually a bugfix, not a bug.
If you edit a file, or rename it, the repository should and does
consider this a change to the file. But the question here is about
what should happen if the file does _not_ change, but a parent
directory is copied, i.e., branched. (Yes, "copied", it is the same
behavior here as a rename.)
I believe the 1.6 working copy is in error. To see why, drop the last
part of your script, where dir2/file is moved to ., and instead add
this:
cd ..
svn cat file://`pwd`/svn/dir2/file
svn export file://`pwd`/svn/dir2/file; cat file
You will see that outside the context of the original working copy,
'file' is shown as being last changed in r2, not r3. This is true in
both 1.6 and 1.7. It is true for both 'svn cat' and 'svn export'. The
only disagreement is inside the 1.6 working copy. It is a bug that
probably arises from limitations of the 1.6 working copy format, in
which copying or renaming a directory is much more cumbersome (behind
the scenes) than it should be. The 1.7 working copy format is much
cleaner for things like this.
If this behavior seems counterintuitive, consider Unix file timestamps.
They are similar, except that 'mv' always preserves modification time.
But the inode change time (ctime) treats a file rename as an update.
Observe - 'ls -c' shows the ctime instead of the mtime:
$ mkdir dir1; touch dir1/file; ls --full-time -c dir1/file
-rw-r--r-- 1 peters peters 0 2012-06-19 01:02:35.072625356 -0500 dir1/file
$ mv dir1 dir2; ls --full-time -c dir2/file
-rw-r--r-- 1 peters peters 0 2012-06-19 01:02:35.072625356 -0500 dir2/file
$ mv dir2/file .; ls --full-time -c file
-rw-r--r-- 1 peters peters 0 2012-06-19 01:02:51.072507177 -0500 file
Thanks for the report,
Peter
--- End Message ---
