SSIS version controlling + subversion

Question

I got a situation where need to maintain version controlling on SSIS packages. Subversion is in place for other .net apps. Now want to move ssis packages to subversion.

got ssis solutions as below:

• ProjectA

  • solution
  • dtsx1
  • dtsx2
  • dtsx3

• ProjectB

  • solution
  • dtsx1
  • dtsx2
  • dtsx3

what are the best practices to do this.

How can Developer-A and Developer-B work on same dtsx package - commit. How well subversion is dealing with ssis conflicts ?

any guidelines please

thanks

Answer 1

I've recently been using subversion to control a suite of DTSX packages, and I must confess that they don't lend themselves too well to this sort of version control.

The first problem you have is that changes to the underlying file from the IDE tend to happen without you realising. A slight move of a component might do this, but more often than not, its something you're not even aware of. Try it: Open a package, check the properties of a few objects, look at a few things without changing anything then save the package. I'd be willing to bet something has changed. The change won't affect the functionality at all, but is annoying for source control purposes.

When conflicts are concerned, sometimes subversion will create other verions of files in the folder, and insert comments within some of the files. These completely break the package, so you have to strip them out.

The nature of the changes saved to the dtsx file also make it completetly implausable to leverage any sort of braching/merging functionality, as you just don't know what you're going to get out at the end!

Despite this, I would still use subversion. It just that you may find more work overhead in managing contentions/conflicts. Personally, I would have one solution per dtsx - this would help reduce any conflicts over use of the project file.