> It wouldn't make a difference in speed. If you fetch the status of a
> single file, it's the same as if you fetched the status of the whole
> folder, well almost. You see, the biggest performance hit are the file
> accesses to the files in the .svn folder and the entries file. So if you
> fetch the status of a file, the number of files accessed internally by
> Subversion is the same as if you fetch the status of all files in the
> same folder.
> The only difference is that it is faster to fetch the status of one file
> than of all files in the folder if the files have a changed "last write
> time" but still are at status 'normal'.
>
> So your proposal would not help to improve the speed (or lets be more
> specific: it would improve the speed but no one would even notice it)
> but would cause a *big* codechange and mean a lot of work.
>
> Just think about the algorithm needed to check which files to fetch the
> status for and then decide if the status of each file should be fetched
> separately or if it would be faster to just fetch the status of all
> files in the folder.
Thanks for the reply.
Your explanation is based on a single directory only - which is at least
in my case a pretty uncommon use case (Java development). Right now, my
java root directory (selected for the commit call) contains ~1200
directories (.svn and its many sub folders already excluded), which
could make a difference if TSVN would scans some of them instead of all.
The scan for each commit takes at least ~30s currently.
Anyway, if it is too much work and if this is not often requested its
fine not to implement the improved status fetching, but would it be
feasible to at least reopen the commit dialog automatically again
(optional of course)?
Ronny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Jul 11 19:12:45 2005