Reputation: 1948
We are currently using SourceSafe at work and I would really like to move away from it. My boss is ok with that on principle, provided we can take our whole history with us. My first approach was to look at SVN and ways to migrate there. But I discovered that SVN does not support shared files.
Or do I have to find a way to convince my boss to let go of that particular feature. Obviously there will be workarounds for most systems but that would already be a much harder sale for me.
Obviously automated and something that runs on windows. I'd also be interested to learn about caveats and problems associated with individual migration tools.
Thank you.
Upvotes: 2
Views: 1662
Reputation: 14052
A. You might want to take a look at Source Gears Vault. I've never used it in anger but it looks to be the only thing out there that has a similar look and feel to VSS.
B. Once again Vault is probably your best option. VSS converter for TFS does, however it's likely that most of your labels won't get migrated. As for other version control systems I'm not sure.
So Vault will meet number 1, keep the boss happy. I've never used it so it might not be very good, but it's billed as VSS without the corruption. I think they offer a trial version so I'd download it and have a play. It is a commercial product though so if you have a requirement for a free (as in beer) tool then this might not work for you.
If you want to go the extra mile, and do number 2 then you're looking at SVN, TFS, git or Mercurial. All of these are very different from VSS and all of them have thier little quirks.
Migrating to any other version control system from VSS is going to be painful. There isn't anything out there, other than perhaps Vault, which completely replicates the way VSS behaves.
Another poster has suggested going to TFS. I've just migrated 100 or so VSS repositories to TFS and in my opinion it's a much better product. Having said that, there will be a lot of learning and planning involved.
VSS uses a lot of conventions that aren't available in other systems, so you need to take a step back and look at why you do stuff and not how. Once you've figured out why you use features such as sharing and pinning, then you can plan how you'll use the features of whichever version control system you pick to replace VSS, to get the same results.
If like me, you work for a company where the majority of developers have only ever used VSS for source control then you also have to factor in that they will require some sort of training. I've found that VSS poisons the mind, and our developers and configuration managers have had real difficulties in getting their heads around branching and merging code.
As for the history, even though your new tool of choice may well migrate the full history. You still have to be aware that any Shares, Pins or Labels will probably not be available to you post migration. In a number of instances we decided that the best option was to "get" a known valid version of the code and migrate that. In those instances the VSS repositories were made read only so that the history was still available if required.
All of the above is based on my own experiences migrating from VSS to TFS but I suspect that it applies to any of the other version control systems you will come across. Whichever tool you decide to use, good luck!
Upvotes: 1
Reputation: 41882
I can recommend migrating a repository from VSS to Team Foundation Server (TFS) it's a smooth and painless process using the VSSConverter.exe tool bundled with TFS. It also moves across your VSS history.
You can drop shared files and use branching instead, which is much more useful and powerful.
Upvotes: 1