On Jan 4, 2012 1:34 PM, "Joe Schaefer" <joe_schaefer_at_yahoo.com> wrote:
>
> As Daniel mentioned to me on irc, subversion doesn't use threading
> internally, so things like client side commit processing and merge
> operations are done one file at at time IIUC.
>
> Over in the openoffice podling we have a use-case for a 9GB working copy
> that regularly sees churn on each file in the tree. commit and merge
> operations for such changes take upwards of 20min, and I'm wondering
> if there's anything we could do here to reduce that processing time
> by 2x or better by threading the per-dir processing somehow.
>
> Thoughts?
We've always taken the position that the amount of effort or size of
delta/data is proportional to the size of the change. If you change all of
a 9Gb working copy, then you should expect svn to take a good chunk of time
and space.
IOW, stop doing that :-)
That said, even if we were desirous of "fixing" this(*), we would have a
hard time doing it using threads. The Subversion client is pretty solidly
single-threaded. We take no precautions for operation in a multi-threaded
app.
Cheers,
-g
(*) I'd be interested in what they are doing. Is this a use case we might
see elsewhere? Or is this something silly they are doing, that would not be
seen elsewhere?
Received on 2012-01-05 01:09:15 CET