This post originated from an RSS feed registered with .NET Buzz by Raymond Lewallen. Original Post: How I migrated from Visual SourceSafe to SourceGear Vault - A Walkthrough Feed Title: Raymond Lewallen Feed URL: /error.htm?aspxerrorpath=/blogs/raymond.lewallen/rss.aspx Feed Description: Patterns and Practices, OOP, .Net and Sql Latest .NET Buzz Posts Latest .NET Buzz Posts by Raymond Lewallen Latest Posts From Raymond Lewallen

Note: Due to the nature of the project I was converting, I cannot supply screenshots, my apologies.

I recently worked on a project where the source control software needed to change from VSS to Vault.  While this is easy enough using the SourceGear Vault Import Tool, there were some other things that needed to happen in order to merge solutions and projects together.  Here’s how I did it.

I installed Vault 3.1.7 Server on a machine running Sql Server 2000, and the same version of client tools and the import tool on another machine running Windows XP SP2.  The first thing I did was set the “admin” password for Vault.  You must use the admin accounts when using the Vault import tool to migrate source from VSS to Vault.  The windows account that I use on the client machine, where my client tools were going to be installed, I made sure I had administrative rights on the server where everything was going on just to avoid any problems I was not aware of.  I was also under a time constraint, so this makes things easier, although I’m not sure if it is necessary to be a member of the Administrators group on the server.

I added my Vault license into the license tab in the Vault Admin Tool.

The next thing I did was set the server options using the Vault Admin Tool.  If you are going to map your Vault users to domain accounts, you have to set the “Active Directory Domain” in server options so that Vault knows where to look for user mappings.  This is the only thing I changed in server settings.

I setup a new repository in Vault using the Admin tool.  This is the single repository where I wanted multiple VSS databases to be imported into.  I then setup a single account, using Windows Directory Services mapping for the passwords, for myself and gave myself administrative rights by adding myself to the only group that is predefined in Vault, the Admin group.

Next I setup the Repository options under the Repository tab in the Vault Admin Tool.  I chose my new repository.  The only thing I set here is the property for “Require Check In Comments”.  I left everything else as default.

I also setup accounts for all the current developers that will be using the code base from Vault.  This is done under the Users tab of the Vault Admin Tool.  I did the same thing for these users, mapping their accounts to windows accounts so that passwords will match the domain accounts.

Next came setting up default permissions for each of the new user accounts in vault.  By default, the settings are Read, Check In/Check Out, and Add/Rename/Delete.  For a couple of users, I changed their default permissions.

Next thing I did was make a backup of the database using the Backup tab in the Admin tool.  I also setup a maintenance plan in Sql Server to make periodic backups of my database from Sql Server.

Now comes the fun part.  I had multiple VSS databases that I wanted to merge into a single repository.  First thing first though, and that is to import the existing code bases into Vault.  For each VSS database that I had, I created a folder in my repository.  Then using the admin tool, I began importing each VSS database into that repository, into its own folder.

The importing is fairly straightforward.  You have to use the admin accounts for both Vault and VSS in order to access and import the databases into Vault.  Everything is as far as the importing is set to default and works fine except 2 things:

1.     I set “Enable Folder Security” for each database that I imported.

2.     You may have users that changed code in your VSS database that no longer work in that code base or even have accounts in your domain.  When importing VSS to Vault, you need to map the VSS users to Vault users so that history can be accurately maintained.  You may need to create new users (can be done from the Import tool) to map the old users to Vault users.  You can then go into Vault and disable these user accounts so that they are not active.  If you want, you can always map old users to an existing user even though they may not be the same person, but I don’t know what happens to history and audit information if you do this.  I created new accounts for my older users and simply disabled their accounts in Vault.

Again, the import tool is straight-forward.  I never encountered any errors, so I’m not sure what to tell you if they happen to occur.  The import can be time consuming though.  You have to remember, if you VSS database has 10 files in it, and you have changed each of those files 10 times, that’s 100 files that have to be imported, because you are also importing history so that you can rollback changes once you get into Vault.  You can imagine what it would be for 100 files that have each been changed 100 times.  The imports can literally take hours, and did for me in a few cases.

I had many databases that had to be imported into Vault.  After each import, I made a backup of my Vault database using the Backup tab in the Vault Admin Tool.  Incase an import went bad, I wanted to be able to restore a good, clean backup and attempt the backup again.  Fortunately for me, all my imports went well and I encountered no errors.  Even though that was the case, it’s certainly no reason not to do backups and periodic intervals during the import processes.

Now I have everything imported into a single repository.  I verified that history and comments made it in the imports by checking random files after each import, and all was well.  My next step was to merge multiple Visual Studio solutions into a single solution, and merge several projects into fewer projects.

My first step was to get rid of the solution files and project files that would no longer be needed.  I did this using the Vault Client Tool and deleting files.  I then “branched” files from one location to another, putting files from a deleted project into the folder with the other files that I wanted to combine into a single project.  One I had branched all my files that I wanted moved, I deleted the original files from their original locations.  I now had my structure setup and was ready to create a new solution and add new projects using Visual Studio.

The next thing I did was to get all the files that were in source control and download them to my local hard drive.  I did this by using the “Get Latest Version” in the Client tool.  Now that I had all the files I needed, I opened up Visual Studio.  I create a new solution in Visual Studio and saved it to the root folder of where all my files are located on my hard drive.  I left a couple of the original projects intact, and deleted some others after moving their files, as was noted above.  I added the existing projects that I just got from source control and added them to the solution.  I then added the files that I had “branched” over from the projects I deleted to the still existing projects.

At this point, I now have my solution, my projects and all their files.  I essentially went from 5+ solutions and 15+ projects into a single solution with 5 projects.  Now, all I have to do is check all of this back into source control, and I’m all done!  Now, because these files exist in source control already, when I do a check-in, its going to tell me that a file with the same name already exists in source control (for the files that I added to the projects), and if I want this file to assume the identity of the file in source control, for each file I check in.  I answer yes to them all and get everything checked in.

This is what took the longest as far as actual hands-on time.  The imports all together took a few hours, but didn’t require interaction from me for 90% of that time.  Branching, adding projects and files, checking files in; this took quite a bit of time because of the size and number of files and required constant interaction from me.  But now that it’s all done, my development time, ability to debug, fix and recompile from directly within Visual Studio is much faster and definitely more efficient.