On Thu, Aug 30, 2012 at 1:12 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 30.08.2012 13:02, Johan Corveleyn wrote: > > But won't the output thread then take just as long, so the user still > > has to wait until that is finished? There is not much point (from the > > users perspective) in having the checkout finished after 25 minutes, > > if the output still keeps coming in for another 25 minutes... > > Network I/O and WC disk operations will not be waiting for console > output, which is what's happening now; they'll both run in parallel. The > total checkout time would be reduced to whichever takes longest today, > console output or everything else. In other words, if your checkout > takes 30 minutes today, and 10 when you redirect to /dev/null, then > there's a good chance that with a separate output thread it'll take 20 > minutes. > I'm not too keen on the thread approach (it must be optional to support systems without threads) but it would elegantly solve another issue: what happens if the output rate drops or if there was an error. An output thread could simply buffer data up to some limit and flush after either that limit was reached or some timeout like .1 seconds. -- Stefan^2. -- * Join us this October at Subversion Live 2012<http://www.wandisco.com/svn-live-2012> for two days of best practice SVN training, networking, live demos, committer meet and greet, and more! Space is limited, so get signed up today<http://www.wandisco.com/svn-live-2012> ! *
