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

Re: [PATCH] Issue 2607: svn keeps rewriting .svn/entries for committed items once for each item

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: 2006-09-11 23:33:44 CEST

On 9/11/06, Philip Martin <philip@codematters.co.uk> wrote:
> "Garrett Rooney" <rooneg@electricjellyfish.net> writes:
> > On 9/10/06, Erik Huelsmann <ehuels@gmail.com> wrote:
> >
> >> + /* Write our accumulation of log entries into a log file */
> >> + SVN_ERR(svn_wc__write_log(adm_access, log_number, logtags, pool));
> >
> > I honestly have no idea here, this isn't my area of expertise, but is
> > holding the log data in memory like that a good idea? Is it
> > potentially big? Should we be appending to a temporary log file
> > instead? Or is this just "the way it's done"?
> The wc library supports multiple log files: log, log.1, log.2, etc.
> and it was introduced to solve a similar entries rewriting problem
> during update. I don't know whether Eric intended to use multiple log
> file or not, his patch introduces the log_number variable but never
> increments it.

Yes, I did do it with intent, because performance degraded between the
original and the version which used several logs. The log_number
variable is a left over from that era (which I found and deleted
locally already).

I have a different problem now though: I'm not getting the same
measurements I got yesterday. So, I can't be sure either version is
faster :-(

Given that I found 1-item logs to be between 190 and 230 bytes, a
post-commit of 50.000 items would require a log file of 10 MB. That
justifies the 1-logfile-per-target approach (since we can't append



To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Sep 11 23:34:22 2006

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.