Re: Bug in Subversion regarding file attributes

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
     lesmikesell_at_gmail.com