Am 24.01.2011 08:57, schrieb Stefan Wild:
> 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)
sorry, the delay is between transferring the last file and showing the final "xxx Bytes transferred in x minute(s) and xx second(s)".
Today it was "636 kBytes transferred in 4 minute(s) and 19 second(s)", "Merged:2 Added:70 Deleted:5 Updated:223". There were about 30s delay before the first file and 53s after the last file...
--
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=2700062
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2011-01-24 09:20:12 CET