On Wed, 29 Jun 2005, Philip Martin wrote:
> "Peter N. Lundblad" <peter@famlundblad.se> writes:
>
> > My assumption is that only a small nuber of files are modified in the
> > typical case. Say my WC have 1000 files and I modified 10. Then I put my
> > WC on a FAT memory stick so the timestamps get screwed.
>
> [...]
>
> > It's hot and late and I've many things in my head, so please explain what
> > I'm missing:-)
>
> What your missing is that "timestamps get screwed" is not normal
> operation as far as I am concerned. As far as I can see, storing the
I may have misinterpretted Erik's comments a few posts back in this
thread. OTOH, screwed timestamps have been reported as a problem several
times in the past. There are even a discussion about the cleanup
workaround in the latest TSVN release notes.
> working file size is likely to be an improvement for anyone using
> Subversion in a conventional development environment. The major
OK, I didn't mean wc-size isn't an improvement for some cases. But I don't
think it is the most important improvement to speed up status. I still
think the typical case is a small percentage of files being modified in a
working copy. So the important code path to optimize is the path taken for
unmodified files. This is guesswork from my side; real measurement would
make better decissions.
> implementation difficulty is that the IO abstraction layer hides
the
> stat() call so the the size information is not readily available where
> needed, but that's hardly a showstopper.
>
I don't mind using svn_io_stat in some more places. Or even a new stat
function that gives us what we use, like node kind/special status,
affected time, size etc. hiding the real stat, but not splitting it up
like we do currently.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 30 21:50:37 2005