Announcement

Collapse
No announcement yet.

Svn takes too muching time in switching brunches, cleanup

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Svn takes too muching time in switching brunches, cleanup

    i Have svn 1.6 version i have Repository of 4GB while performing any operation like swiching,claning on this repository some user faces slow down or it takes very long time , client uses tortoise svn client tool.

  • #2
    SVN 1.6 is very old. Have you tried the same operation using SVN 1.9 ?

    Comment


    • #3
      yes i tried on svn 1.9 same issue

      Comment


      • #4
        In general with Subversion, the overall repository size is not important. It is the working copy size that matters. Ignoring the ".svn" directory tree, how many files and directories are in your working copy? Also, how many files are in the directory that contains the largest number of directory entries (files, directories, symlinks)?

        Comment


        • #5
          on user pc shows 7.18GB size and it contains 147,360 Files, 27,294 Folder

          Comment


          • #6
            Hi sir
            can you pls reply

            Comment


            • #7
              Sorry - missed your post.

              That is a *huge* working copy. Guess I'm not surprised that the UI and other operations are slowing down. A switch will require verifying that every file is what it should be and there's a lot of I/O to do that.

              Not sure what you mean by "cloning" - that's a Git term, not Subversion? If you mean "checkout" then that will need to transfer all of the data for the working copy and place that data into the appropriate places (as well as keeping a copy in the working copy's "pristine store" in that ".svn" directory tree). All of that will also take I/O time.

              If you haven't already you might want to switch to using an SSD (no spinning rust) and invest in fast networking.

              Finally, what is the "latency" (ping time) between your Subversion client and the Repository server? Large latencies will mean that the I/O time will blossom the time to complete the checkout, switch and even update operations. This is where WANdisco's "Subversion MultiSite Plus" product can really help (FYI, full disclosure, I'm the product manager).

              Comment


              • #8
                Thanks for reply
                "latency" (ping time) between your Subversion client and the Repository server is 1ms and TTL is 64 , please suggest how to solve this issue but this issue faced by 1-2 users and other user not face this issue as all user are working on same Repository.
                Last edited by amartlk; 09-28-2017, 05:20 AM.

                Comment


                • #9
                  Since the latency is low (1ms) that's not the problem.

                  You probably want to compare the client machines of the staff where the problem exists with the client machines of the staff where the problem does not. Things to compare:

                  1. Hard drive vs. SSD (use SSD)
                  2. Different network interface controllers (are they seeing 1Gb or 100Mb ?)
                  3. Amount of free space on the client file system (if they're getting close to maxing out the file system - within 10% - then file system operations will slow down)

                  Comment


                  • #10
                    Thanks for reply
                    it is observerd that it when we get fresh checkout in client machines then it work fast but after some days it again slow down ,and i also observed that the client machines where problem does not existt has 8 gb Ram(memory) where client machines which has problem has only 4 GB(memory) can this also make issue ?
                    and both has network interface controllers 100 Mb.

                    Comment


                    • #11
                      If the client machines with 4GB RAM are having trouble and the client machines with 8GB RAM are fine then you've found your root cause. This working copy is huge and it is likely that keeping track of all of that data is taking up a log of RAM. And system RAM has to do a lot more than just handle the SVN data so it should be significantly larger than your working copy.

                      The reality is that the working copy is going to grow over time. It's currently over 7GB so it's closing in on being the same size as the users who have 8GB RAM. I would suggest that, at least for those users who are working on this huge working copy, their systems should be upgraded to have at least 16GB RAM.

                      Comment


                      • #12
                        Thanks for reply but I can't understand if repository size is 4 GB then after checkout it is around 10 GB? And how ram responsible for slow operation

                        Comment


                        • #13
                          Data stored in repositories is compressed. When extracted into working copies it must be fully re-constituted.

                          RAM must contain all of the data used by the SCM program *and* all of the tools that the users are using to develop whatever it is that is being stored in those files. And cache disk space. And handle all of the networking, etc. If the OS starts to run out of RAM it will put data onto it disk/SSD. That means accessing it is 1000X slower than having it in RAM.

                          Comment


                          • #14
                            Hi
                            while checkout from svn tortoise i get below error REPORT of '/SVN/smartfactory/!svn/vcc/default': 200 OK while user are able to check out in another pc

                            Comment


                            • #15
                              Somehow the error did not get into your post. Note that a return result of "200" is just fine and NOT an error.

                              Comment

                              Working...
                              X