For the last 10 odd years, the game’s data components have been kept in Visual Source Safe. VSS is bad, m’kay. Like any piece of software, it has its merits, especially for a very small team working on a very simple project. I’m not going to turn this into an anti-VSS pejorative tho.
Moving from VSS to Subversion (and then possibly Mercurial) varies in complexity depending on your repository. Ours is ten years old and contains multiple projects, which have danced around the directory tree.
For our non-Windows access to the VSS repository, we use SourceGear‘s SourceOffSite. Or we were doing, version 5.0 of this cross-platform supports a reduced list of platforms: Windows 7, Windows Vista, Windows … Ok – it’s Windows only.
Still – one neat aspect of the Linux client is that it comes with a command line utility for talking to the SourceOffSite server (which sits on the same machine as the VSS data).
Just when your hopes get up, though, the command line utility turns out to be really atrocious to work with. It has an “interactive” mode which is supposed to speed up the connection to the server. Except, it doesn’t actually do that. It just saves you having to type the “soscmd” infront of all the commands you want to type.
After looking at numerous VSS to SVN import tools, I found that none of them were going to achieve what I wanted in a way I wanted … so … I finally buckled and wrote a fairly simple ‘soscmd’ wrapper in Perl which is, even now, going through the VSS repository and finding all the files stored under the data project. It then looks up the current version, and then it gets the project history to that version.
Since VSS processes commits on a per-file basis, I’m then combining all of the commits by a given user within a few seconds of each other to create SVN/Hg style check ins.
It spits all of this out as a secondary script – because it’s so bloody slow that I don’t want to have to run it twice, so I figure I’ll get this part done and then use the secondary script to finish the process, which involves checking out files from SourceOffSite one by one up to a specific revision and then checking them in.
It won’t handle renames and moves etc, since VSS handles these badly. But it does at least mean that we’ll have most of our 10 year data history for all the files that we have currently.
When I say slow … It’s been running for 2 days now and is just about half way through the data directory tree. *Sigh*
VSS has always been a big ‘sigh’
What is your bottle neck? Actual moving the file, file i/o, or checking it in and out.
download more ram!
Breed: The protocol used to talk to the remote server.
careful with memory leaks while using breed :).
simple multi threading or running multiple instance of the script won’t help then. :(