TortoiseSVN 1.7 extremely slow on commit and check modifications on network share
Anton Palyok
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.
This works fine in a TortoiseSVN 1.6. And "Update" operation in this way also works well.
I want ask developers if they are planning to fix this problem in the near future?
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.
Thanks
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909472
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Andy Levy
> 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.
>
> This works fine in a TortoiseSVN 1.6. And "Update" operation in this way also works well.
>
> I want ask developers if they are planning to fix this problem in the near future?
Are you asking the TSVN developers if they're going to fix a perceived
regression in TSVN when it's used in a way that it shouldn't (even
though isn't disallowed) be used in the first place?
> 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.
"Votes" on Stack Overflow don't have any significance here that I'm aware of.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909477
Anton Palyok
Do you know how to solve my question?
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909480
Stefan Küng
> 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
Andy Levy
>> 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 think the OP needs to clarify this. What does "busy" really mean
here? There are a number of servers in my environment which have a
very low limit on the number of RDP connections allowed (2 I think),
but when both are occupied the CPU & network interface may be at
single-digit utilization. In that context, the server may be "busy"
but it's not actually short on resources.
Regardless, I agree that accessing the WC over the share is not advisable.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909491
Anton Palyok
Let me clarify something:
> Sure it works. As does 1.7.x. You failed to mention how long it takes
> with 1.6 to do this.
At the 1.6 version it works very quickly: 10-15 seconds.
> Fix? Fix what exactly?
> * your server is busy
> That means accessing a network share doesn't get full bandwidth because the
> bandwidth is already used up by your RDP sessions.
As levyam have mentioned in a comment above I meant that server is busy for login to it (no RDP connections). CPU and others resources of the server are OK.
Now you can forget about it. This issue still reproduce when server doesn't have any load.
I ask this question because it worked very well and it was a very useful feature, it saves a lot of time. Many people will agree with me.
So it would be nice if it could work like early versions.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909506
Stefan Küng
> Thanks for you answer.
> Let me clarify something:
>
>> Sure it works. As does 1.7.x. You failed to mention how long it takes
>> with 1.6 to do this.
> At the 1.6 version it works very quickly: 10-15 seconds.
>
>
>> Fix? Fix what exactly?
>> * your server is busy
>> That means accessing a network share doesn't get full bandwidth because the
>> bandwidth is already used up by your RDP sessions.
> As levyam have mentioned in a comment above I meant that server is busy for login to it (no RDP connections). CPU and others resources of the server are OK.
> Now you can forget about it. This issue still reproduce when server doesn't have any load.
>
>
> I ask this question because it worked very well and it was a very useful feature, it saves a lot of time. Many people will agree with me.
>
> So it would be nice if it could work like early versions.
SVN is optimized for situations that are most used and recommended. That
unfortunately means that situations that never were recommended and in
fact always considered very bad practice are not optimized.
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=2909508
Markus Schaber
Von: Anton Palyok [mailto:anton....@gmail.com]
> First of all:
> I have a working copy that configured to the webserver (not a network share)
> 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.
May I suggest a workaround:
Install a SSH server on the dev server, log in on that server, and use the command line svn client to upgrade the working copy. This is very resource friendly.
There are different SSH servers available for windows, including one from Cygwin, but you should take care that don't use a Cygwin ssh.exe on the same working copy as the windows native clients (simply don't install the Cygwin ssh packages, and extend PATH to cover the bin directory in your Tortoise installation, for example).
Using batch files, or a cygwin shell file, or similar, you can completely automate the whole thing, reducing your effort to a simple klick on the script on your own PC.
Thanks
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909472
To unsubscribe from this discussion, e-mail: [users-un...@tortoisesvn.tigris.org].
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.sc...@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909654
David Balažic
David
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909664
Ulrich Eckhardt
> Markus Schaber schrieb:
>> Install a SSH server on the dev server, log in on that
>> server, and use the command line svn client to upgrade the
>> working copy. This is very resource friendly.
>
Please don't top-post as that often requires guessing what you are
actually referring to. It also avoids mistakes, like referring to "ssh
client" which Markus never wrote... ;)
Concerning what I guess you meant, the answer is "No". The point is that
you want the SVN client to run on the same machine that hosts the
filesystem with the WC. For that, you use SSH (or any other remote
connection like RDP) to remotely run the SVN client on the according
machine, instead of using a local SVN client with a WC on a remote
filesystem.
Uli
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909712
Markus Schaber
Yes, you're right.
Mixed access of Cygwin and non-Cygwin SVN clients on the same working copy is the problem, not mixing SSH clients.
Thanks,
Markus
-----Ursprüngliche Nachricht-----
Von: David Balažic [mailto:david....@comtrade.com]
Gesendet: Mittwoch, 18. Januar 2012 09:51
An: us...@tortoisesvn.tigris.org
Betreff: RE: TortoiseSVN 1.7 extremely slow on commit and check modifications on network share
David
Best regards
Markus Schaber
--
___________________________
We software Automation.
3S-Smart Software Solutions GmbH
Markus Schaber | Developer
Memminger Str. 151 | 87439 Kempten | Germany | Tel. +49-831-54031-0 | Fax +49-831-54031-50
Email: m.sc...@3s-software.com | Web: http://www.3s-software.com
CoDeSys internet forum: http://forum.3s-software.com
Download CoDeSys sample projects: http://www.3s-software.com/index.shtml?sample_projects
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909719