Excellent, thank you for the detailed response. That makes a lot of sense. I'm going to try another Windows trial...
I did manage to compile on Linux and run the program. When I tried to do it on a test database, I got a "file not recognized" error (don't have the text in front of me). When I looked up this error on google I found a conversation from someone who was trying to migrate on a Mac and began a discussion on endian byte order. I thought this might be my issue as well but my colleague (helpful fellow, him) said that it's processor-specific - Intel Linux will have same byte order as Intel Windows. The only other variable I know about is that our Linux box is 64-bit, but apparently that doesn't matter either. What do you think? thanks again for time and expertise! PS don't forget to CC the list! On Nov 29, 2007 5:31 PM, Jason Winnebeck <[EMAIL PROTECTED]> wrote: > Your colleague is entirely right, on one aspect. The code probably runs > just > as fast on the Linux box as on my desktop. Actually, the code is probably > slower on Linux, in execution speed because the Linux machine is actually > about 4 years old and I think it's something like a 2ghz dual core HT > setup, > but since vss2svn is single-threaded it only runs in one processor anyway. > > The problem is that the conversion isn't a CPU-bound process, it's > IO-bound. > Therefore the speed is limited to the disk access. So really what I am > comparing is filesystem I/O in Windows vs Linux and Linux seemed to do a > lot > better with this job of extreme amounts of small, fragmented access. Of > course > on typical Windows workstations you have anti-virus and loads of IT "crap" > now > and just having McAfee virus scanner enabled slowed the process by several > times. > > If you can do a RAM drive on Windows, if you can use SCSI disks with IO > queueing, or etc, you can get benefits. Actually, I wonder if a USB drive > would be faster than an HD because of the random access of very small > chunks > of data has nanosecond overhead on USB drives but milliseconds on > mechanical > drives. > > Anyway, it's not worth a huge deal to get it over. If it takes a day in > Windows and 5 hours in Linux then it's not worth it. I definitely wouldn't > set > up a Linux machine JUST to do this. But you can try a few things on > Windows, > like USB or whatever and it will be obvious if it is going very fast or > very slow. > > In my plan I actually just started it on Windows and then tried to find > faster > ways and I was actually able to run the solution on my Linux server and > finish > it before the Windows one was hardly kicked off so I just stopped the > Windows > one, again mostly due to RAM disk (which is standard in Linux). > > Jason > > David Blaikie wrote: > > Hi again Jason, follow-up question re your suggestion to run VSS2SVN on > > Linux to improve speed. > > > > 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? > > > > 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? > > > > thanks > > > > David >
_______________________________________________ vss2svn-users mailing list Project homepage: http://www.pumacode.org/projects/vss2svn/ Subscribe/Unsubscribe/Admin: http://lists.pumacode.org/mailman/listinfo/vss2svn-users-lists.pumacode.org Mailing list web interface (with searchable archives): http://dir.gmane.org/gmane.comp.version-control.subversion.vss2svn.user
