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

Re: TortoiseSVN 1.7 extremely slow on commit and check modifications on network share

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Tue, 17 Jan 2012 19:44:25 +0100

On 17.01.2012 18:29, Anton Palyok wrote:
> Hello guys,
>
> First of all: I have a working copy that configured to the webserver
> (not a network share)
>
> This working copy placed on a DEV server. Sometimes when all active
> sessions on DEV server are busy (I can't connect by RDP) then I can't
> do a "Commit" or "Check Modifications" from that DEV server. I
> connect to the second DEV-2 server. I open first DEV server by
> network share, like "\\DEV\Project". Now if I click "Commit" or
> "Check Modification" then dialog appears very slowly (30-40 minutes).
> There are no unversioned files and can be 0 modified files.

Here's how svn detects modifications:
http://tortoisesvn.net/faq.html#detectmodification

It doesn't make any difference how many modified items there are.

> This works fine in a TortoiseSVN 1.6. And "Update" operation in this
> way also works well.

Sure it works. As does 1.7.x. You failed to mention how long it takes
with 1.6 to do this.

> I want ask developers if they are planning to fix this problem in the
> near future?

Fix? Fix what exactly?
You say that you only do this if the dev server is busy (all RDP
sessions used up). Now think a little bit here please:
* your server is busy
* there are too many RDP sessions already open
See something here?
Both CPU and most of all the network on your server is maxed out. That
means accessing a network share doesn't get full bandwidth because the
bandwidth is already used up by your RDP sessions.

> I asked this question on Stackoverlow as well:
> http://stackoverflow.com/questions/8880129/tortoisesvn-1-7-extremely-slow-on-commit-and-check-modifications-on-network-shar
>
>
> Now this question has a few votes. So this issue is actual for people.

No, those votes simply mean that some few people are interested if
there's a workaround. But it doesn't mean it's a problem for them.

A few things to consider here:
* this is an issue in the svn library and sqlite which is used as the db
for working copy metadata. So if you want something done about this you
have to ask on their mailing lists.
* Considering that sqlite is *widely* used in various products out there
and considering that svn always mentioned to *not* use working copies
over network shares because of the performance, I don't think the devs
of sqlite and svn won't give this much attention
* spending time on something that's not recommended anyway is really a
waste of time: that time is better spent on something more urgent

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909488
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2012-01-17 19:44:33 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.