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

Re: Long delay after commit

From: Andreas Stieger <andreas.stieger_at_gmx.de>
Date: Mon, 24 Jan 2011 08:05:19 +0000

On 24 Jan 2011, at 07:57, Stefan Wild <stefan.wild_at_autinity.de> wrote:

> Am 21.01.2011 19:51, schrieb Stefan Küng:
>> On 21.01.2011 10:35, Ulrich Eckhardt wrote:
>>> Hi!
>>> I have the effect that the commit window hangs for some time after sending the
>>> changes. This is not a showstopper, but an annoyance still. I know that the
>>> commit was finished because updating a different working copy actually pulls
>>> those changes from the repository. I'm using svnserve on Red Hat on a virtual
>>> machine hosted on a machine in the LAN. There are a few post-commit scripts
>>> that could influence the timing: three calls to commit-email.pl (which
>>> exclude the diffs) and one for TRAC integration. What I could surely do there
>>> would be to run them in the background ("somescript&"). However, what I'm
>>> wondering is whether these post commit hooks can influence TSVN at all? Or
>>> should I try to look at things happening locally that influence the timing?
>> SVN clients wait for all post-commit hook scripts to finish. That's why
>> most of those scripts should be run in a separate process. For example,
>> the commit-email script should be started as a separate thread so the
>> original hook script (the one that stars the email script) can return
>> immediately. Otherwise if mail servers are slow or don't respond, the
>> SVN client has to wait too.
>> Apart from that: after the commit succeeded, SVN clients adjust the
>> working copy which can also take a while, especially if a lot of files
>> have been committed. If an SVN client were to be interrupted in this
>> state, the commit would show up in the repository, but all the committed
>> files in the working copy would still show up as modified. An update
>> fixes that.
>> So I'm not sure which is the reason for the delays you're seeing. But I
>> would guess it's the first one.
>>> Lastly, drifting further off-topic, can 30k commits in a repository cause any
>>> slowdown in above described components?
>> Yes, such big commits take a while to get processed by the email script
>> (it has to get the diff, prepare the email in memory, send *big* emails,
>> ...).
>> Stefan
> I have the same problem for some months now, but didn't know how to tell... we have no script hooks, neither for commit nor for update. We now have about 5600 files (~70MB) at Revision 6000+, and there's a delay of about 30s after the final "xxx Bytes transferred in x minute(s) and xx second(s)" appears, even if no data was updated or just a single small file was commited. We use svn, version 1.6.2 on a Suse 10.3 server and TSVN client 1.6.11.
> (It used to be faster)
> --
> Mit freundlichen Grüßen
> Stefan Wild
> autinity systems GmbH
> Neefestraße 42
> D-09119 Chemnitz
> Amtsgericht Chemnitz HRB: 21552
> Telefon: +49 (0) 371 918557-00
> Fax: +49 (0) 371 918897-49
> email: stefan.wild_at_autinity.de
> web: www.autinity.de
> ------------------------------------------------------
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2700048
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-01-24 09:04:40 CET

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.