Hi again Jason, follow-up question re your suggestion to run VSS2SVN on Linux to improve speed.<br><br>I ran this idea by a colleague and he felt that, since the core functionality is compiled C, that it shouldn't run much faster on a Linux machine. Do you have any idea why this would have been the case for you? Was it because your Linux machine was just faster, or because you were using a RAM disk?
<br><br>Just because of our own hardware setups, it would take a great deal more time and trouble for us to move our repository to a Linux machine and would be easier to do so on a Windows machine. I would like to get more information before going forward with the Linux idea. Can you or anyone else on the list offer any more thoughts on this subject?
<br><br>thanks<br><br>David<br><br><br><div class="gmail_quote">On Oct 10, 2007 5:25 PM, Jason Winnebeck <<a href="mailto:gillius-ml@gillius.org">gillius-ml@gillius.org</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
David, if you want to keep the topic on the list remember to continue to<br>include vss2svn users e-mail.<br><br>40GB sounds huge to me. I hear people speak of repositories that large, and I<br>don't know how it gets that way. Probably because we only use it to do source
<br>code. I converted a repository some months ago that represented 5 years of<br>development of a team of 1-5 developers. The converted SVN repository (1.3,<br>not 1.4 style) is 200MB. I considered that large. I don't think I would envy
<br>having to deal with a 40GB job.<br><br>I noticed that when I ran the script on Linux it ran many times faster than on<br>Windows (hours to minutes). When I ran the vss2svn script on a Linux RAM disk,<br>the process went from many minutes to a few minutes. The conversion process
<br>and the subsequent svnadmin load are extremely I/O intensive and make lots of<br>small writes. I suggest you use whatever is the fastest storage media you can.<br>In fact, if you have more than one HD on a server, I suggest hosting VSS on
<br>one and vss2svn output on the other and reversing that to minimize the<br>switching of reads and writes, which kills HDs. I noticed when I was doing<br>partition resizing with gparted to move file systems around it was going to
<br>take an entire DAY to move the partition on the drive to another location, but<br>it took 15 minutes to move it from disk A to disk B then from B back to A in a<br>different location. Sequential reads vs random reads make or break this.
<br><br>If you make the process fast enough, perhaps if you have to convert the whole<br>thing it won't be so bad. Extra memory or disks help.<br><font color="#888888"><br>Jason<br></font><div><div></div><div class="Wj3C7c">
<br>David Blaikie wrote:<br>> Jason, thanks a lot for your knowledgeshare. I will try a few different<br>> things and see what might work. Perhaps I'll try to run the script on<br>> the whole 40GB. Does 40GB sound like an inordinately massive project?
<br>> I've seen messages on this list saying that 10GB is large. If we've<br>> been building this thing up over the last 5 years, am I facing a Holy<br>> Grail - type situation?<br>><br>> thanks again
<br>><br>> David<br></div></div></blockquote></div><br>