On 8/21/11 11:07 PM, Andy Canfield wrote:
WOW! So the .svn hidden directory contains a spare copy of every file in that
directory??? Why not just store a computed checksum?
The theory is that disk space is cheaper than a fast network. And sometimes it
is true... It also lets the client do some operations (status/diff) offline
and reduces the load on the server.
This means that putting a directory tree under version control doubles the size
of your working copy!
As you might note from the time it takes to create it.
[3] If a file has changed it will be uploaded in the commit.
I believe it sends some sort of diff containing the changes.
[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.
System attributes aren't maintained at all.
[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.
Just don't count on reproducing system attributes. If they matter, make a
script to set them correctly.
[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?
I think this is controlled by the system defaults (process owner and umask on
linux), not the source material.
--
Les Mikesell
lesmikes...@gmail.com
