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.