On Mon, Aug 22, 2011 at 12:07 AM, Andy Canfield
<andy.canfield_at_pimco.mobi> wrote:
>
>
> On 08/21/2011 10:52 PM, Mark Phippard wrote:
>
> On Sun, Aug 21, 2011 at 11:03 AM, David Weintraub <qazwart_at_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!
This means that Subversion "working copies" take twice as much space
as an "export", of merely the current files.
The local snapshot is to make "svn diff", "svn revert", "svn commit",
and other commands have something local to compare the contents
against and operate far, far more efficiently. I once had to deal
with an in-house source control system that manipulated hardlinks
instead. That turned out to be...... nasty to maintain, and I was very
happy when we migrated to Subversion.
> 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.
Except that local comparisons are one heck of a lot faster than
executing them against a remote repository. This sort of comparison is
*inevitable* with any source control system. Subversion's is not
necessarily ideal, but is based on the older "CVS" model, which if you
look under the hood was based on RCS.
The information has to be stored *somewhere*. Keeping the pristine
local copy makes a lot of operations more efficient.
Received on 2011-08-22 07:02:19 CEST