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

Speeding up the 'svn commit' process?

From: Justin Erenkrantz <jerenkrantz_at_apache.org>
Date: 2002-07-10 12:05:39 CEST

My current gripe is that 'svn commit' just takes too long to pop
up an editor. This seems to be related to the efficiency of
svn_client__harvest_committables function. It is taking me about
10-15 minutes for my editor to pop up with the list of files that
are changed. My starting point is a linux-2.4.14 kernel tree and
then I'm trying to upgrade to 2.4.15, 2.4.16, 2.4.17, etc.

As I know this is something that has been brought up before, but
boy are we reading the .entries files too much. It currently
looks to be a 2:1 ratio. For a directory with about 512 files,
SVN parses the .entries file about 996 times. IMHO, that's about
995 times more than it needs to. For each time it parses the
.entries file, it reloads and reparses the XML file.

So, what would we have to do to keep a single copy of the parsed
entries file and pass it around everywhere? Should I just start
trying to add entry to functions and go from there? I believe
the second entries parsing comes from svn_wc_props_modified_p -
which has the distinction of not wanting info on deleted files.
I think we can work around that even if we have the complete
entries for that directory (no need to re-read it).

Thoughts? It's obvious people have thought about this before
and gave up. So, before I start down this road, I'd like to
get feedback from those who tried before. =) -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 10 12:06:06 2002

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.