From VSS to Subversion - things to watch out for

Question

We have a SSIS, SSRS and SSAS code repository in VSS that we are moving to Subversion.

We have made the sane choice of keeping history in VSS and are making it read-only.

I am going to download my entire structure, make it writable, remove all VSS files and VSS info from the Solution and Project files, and then import it into Subversion.

My question is:

Going from VSS to Subversion, what are the things to watch out for?

Anything specific to SQL Server packages that I should watch out for?

Answer 1

I noticed that when I did a rollback once SVN corrupted the SSIS package because it added comments to the package .dtsx file

Answer 2

You can use AnkhSVN for Visualstudio Integration. SVN has it's own storage format.

You might need a new Bugtracking System.

Answer 3

We did the same a few years ago (from VSS to SVN).

First of all, educate your developers regarding the different philosophy of SVN versus VSS.

• In VSS we 'reserved' files (meaning that other developers couldn't reserve the file anymore), then made the changes, and then committed the files again. This is the lock-edit-unlock principle.
• SVN uses the fetch-edit-merge-commit principle. Your developers may have mixed feelings about this since they are not sure anymore they are the only once being able to edit a file. Convince them. Our development team has grown to about 15 developers and so far we had never merge conflicts that went unnoticed.

Second, consider porting a minimal history from VSS to SVN. It may be overkill to copy every little history detail from VSS to SVN, but it still makes sense to copy e.g. every release of the last 5 years of your application to SVN.

Third, investigate the features of SVN that don't exist in VSS. Some of them might open up new possibilities in your organization. A very good one is the 'revision' concept. VSS has no global revision number, meaning that it is difficult to refer to an exact situation (unless you start labeling everything). In SVN, the revisions make it possible to refer to any point in history of the SVN repository. You could use the revision number e.g. in your build process (e.g. release 1.0 of your application could be revision 12345, you could integrate the revision number in your bugtracking system, ...).

Fourth, use additional tools like TortoiseSVN (Shell extension) and VisualSVN (Visual Studio add-on).

Answer 4

Some files are almost impossible to merge textually, SVN is very merge heavy, so this can trip you up. Any XML files that mix layout and structure are trouble because of this. The people I've seen use SSIS type stuff try to avoid merges at all cost.

Be aware of that and you can arrange your workflow to minimize the problem.

Answer 5

with SVN, you might want to just make sure you keep out unnecessary files. /bin directory, /obj directory, .user files, .suo files

Using VisualSVN with Visual Studio will help, as well as something like Tortoise in Windows Explorer. In SSRS projects, the datasources don't automatically get added by VisualSVN, you have to add them manually in explorer, just a caveat.