[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Bad performance with large binary files

From: Erik Huelsmann <e.huelsmann_at_gmx.net>
Date: 2004-04-07 18:17:09 CEST

[ about timestamps in the entries file ]

> > My understanding is that whenever libsvn_wc discovers that a file is
> > unchanged (by brute-force means), it changes the timestamp within the
> > .svn/entries file to match the current working-file's timestamp. Thus
> > "reinstating" the optimization. Didn't Philip add this feature?
> I did, but it's not quite as you describe: only libsvn_wc operations
> that take a write lock are able to fix out-of-date timestamps. Thus,
> in practice "svn commit" and "svn revert" are the only commands that
> both detect the out-of-date timestamp and take a write lock. There
> was a brief discussion about adding an explict "svn fix" or perhaps
> "svn st --fix".

Since "svn cleanup" does not do file status checking, it is not something to
add there, is it?

Cleanup seems (at first thought) a logical point to add it, since it already
is a command for bringing working copies back into tip-top shape; write
access to the working copy is required and the command may already do some
rewriting on the entries file. On the other hand, it would require additional
status scanning - even in cases where it was not needed before.



NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 7 18:17:28 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.