On 08/21/2011 10:52 PM, Mark Phippard wrote:
On Sun, Aug 21, 2011 at 11:03 AM, David Weintraub <qazw...@gmail.com
<mailto:qazw...@gmail.com>> wrote:
What Subversion does is look at the timestamp of the file and the
contents of the .svn directory that contains the file information. If
the timestamp has been touched, it is compared against the base to see
if there was an actual change. If you modify a file's property, it
changes an internal file in the .svn directory and Subversion picks up
that timestamp change.
Just a point of clarification. Subversion looks at two things to
determine if a file has changed.
1. The timestamp
2. The size
If the file size has changed, then SVN considers the file modified.
If the file timestamp has changed, then SVN does a byte for byte
comparison with the pristine version of the file to determine if it
has changed.
WOW! So the .svn hidden directory contains a spare copy of every file in
that directory??? Why not just store a computed checksum?
This means that putting a directory tree under version control doubles
the size of your working copy!
A good way to make SVN really slow is to run touch on your entire
working copy. That forces SVN to have to do a compare on every single
file to see if it has been modifed. svn cleanup will repair the
internal timestamps.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Conclusions:
[1] Subversion will only suspect that a file has changed if either the
timestamp or the file size has changed.
[2] If Subversion suspects that a file has changed it will compare the
file contents with a copy of the file stored somewhere in the .svn
directory.
[3] If a file has changed it will be uploaded in the commit.
[4] File system attributes are only uploaded for a "svn new"; at all
other times file system attributes remain as they were when the file was
first added to the repository. So make darned sure you get the file
system attributes correct when you first add the file.
[5] To correct invalid file system attributes one must copy the file
elsewhere, svn delete, commit, recover from the copy, svn add, and svn
commit again. This works. It is not obvious that this will work, because
although the file disappears from your working copy it is still in the
repository. So svn add uploads the file attributes and svn commit
*could* upload the file attributes but it doesn't.
[6] The only file system attribute Subversion supports is the executable
bit. Otherwise all system attributes are kept as of when the file was
originall NEW-ed.
Does this mean that if a file is NEW-ed under Windows then when it is
checked out under Linux it will be writable by everyone, which is the
default in Windows?
