Concerning RE: Poor performance in windows. Sw
Gavin Lambert wrote on 14 Feb 2007, 12:09, at least in part:
> Quoth Jan Hendrik <mailto:jan.hendrik@myrealbox.com>:
> >> This behavior does exist in Subversion, but I do not believe it is
> >> considered a bug. Rather, I believe it is considered a user error
> >> to modify a file but not update its timestamp.
> >
> > A timestamp reset to an earlier date should be considered even
> > more a user error then, but SVN will happily commit then. At least
> > SVN should provide a --force switch to have it compare ALL files in
> > WC with base, no matter what timestamps say.
>
> Actually no, it won't commit then. At least not if there aren't any
> actual changes.
That's right & OK.
> The timestamp thing is actually a *feature* of SVN, not a bug. It's a
> performance optimisation, since it's a lot easier and faster to check
> the timestamps of files than to check their contents.
True.
> Essentially, when scanning the directory SVN will first obtain a list
> of all files whose timestamps are different from what it was
> expecting. It then scans the *contents* of those files having a
> different timestamp to see if the actual file contents have changed
> (by doing a hash of some kind, probably an MD5, but I'm not sure of
> the exact details). Only those files which have both a different
> timestamp and a different checksum will be considered "modified" and
> will be committed.
>
> You can test this easily yourself -- from a pristine unmodified (but
> versioned) file, make a change and save it. Do "svn st" and note the
> file is listed as modified. Now edit the file again and remove the
> change you just made. Do another "svn st" and the file will no longer
> be listed (because it's no longer considered modified, even though its
> timestamp differs).
I know. Happens all the time here with the WC normally used for
uploading to the live server: commits before the upload are not
committed again, though the upload process changes timestamps.
> If it scanned the contents of all files then the update/commit process
> would be at least an order of magnitude slower than it already is.
That's where the --force switch would come in: Force SVN to do a
hash check, kind of make sure about modifications, no matter what
the first-level timestamp check says. Using a switch like this the
user usually knows what he does.
TortoiseSVN reportedly does kind of similar with their
implementation of cleanup, though obviously rather primitive:
correcting the timestamps in base copy so otherwise not modified
files are no longer scanned. As it did not help me in my case of
unchanged filesizes it looks like TSVN rests on filesize, not
checksums for this:
if ((timestampWC != timestampBC) &&(filesizeWC == filesize BC)):
timestampBC t= timestampWC
JH
---------------------------------------
Freedom quote:
Capitalism is not an 'ism.'
It is closer to being the opposite of an 'ism,'
because it is simply the freedom of ordinary people
to make whatever economic transactions they can mutually agree to.
-- Thomas Sowell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 12:18:51 2007