Home/ Questions/Q 1039209
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T15:04:16+00:00

We have a SSIS, SSRS and SSAS code repository in VSS that we are

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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).

    • 0