1

I've read a couple of other questions/answers on stack overflow regarding this, but wanted to get some clarification if possible.

Situation - we have about 20 dtsx files and want to start using SVN to track changes to these packages - we are aware that using SVN will probably not allow us to merge changes within a package due to the complex XML that comprises dtsx file which is acceptable as SVN will still provide some benefits in change tracking. Currently our development/deployment strategy is that each developer loads dtsx files as needed from the target server, develops locally, and then copies the file back to the target server. Each developer uses his/her own strategy in terms of whether to have a large project with all of the packages included or to create a new project each time a dtsx needs modification, etc.

I'm looking for suggestions on efficient ways to implement SVN in this environment - should the VS project file (for instance) be included in SVN control? If not, how does a developer 'Open a project from Subversion'? Can everything be done within VS or will we need to go the Windows Explorer, Update at the folder level, then Add Existing Package from within VS - and if we do it that way will we still be able to Commit from VS?

Sorry for the basic questions, new to using SVN in this way and hoping for some specific steps.

engil
  • 349
  • 2
  • 13
  • 2
    Can I ask why SVN? TFS is the designated SCM for SSIS. – Dominic Goulet Oct 25 '12 at 18:44
  • 1
    @DominicGoulet Who "designated" TFS for SSIS? We store all our SSIS packaged in SVN and we're quite happy with it. TFS brings many other benefits, but it's a 'heavy' tool and if you only want source control then SVN, Mercurial, git or any other good tool will work fine. – Pondlife Oct 26 '12 at 13:09
  • I'm not sure what your precise difficulty is: it sounds like you are unsure how to use SVN effectively in general, and SSIS/VS is a secondary issue? Have you reviewed the [documentation](http://svnbook.red-bean.com/) and are you comfortable with [general source control usage](http://www.ericsink.com/scm/source_control.html)? Your question is quite open right now and therefore it's not a good fit for this site, can you make it more specific? – Pondlife Oct 26 '12 at 13:19
  • @engil TFS is the "designated tool" because it is the one that Microsoft has included defacto in their products. TFS indeed allows you to use multiple features, but in no way is it 'heavier' than SVN if you only want source control. I would never use anything else than TFS inside Visual Studio, simply because there are so much more to leverage (builds, work items, auto deployment, etc.). – Dominic Goulet Oct 26 '12 at 15:38
  • @Dominic - unfortunately we are not authorized to use TFS by management. I know that sounds ridiculous, but there it is.... – engil Oct 26 '12 at 16:44
  • @Pondlife - admittedly not an expert in svn but have read documentation - have used SVN for general application development but with SSIS due to the inability to merge changes and the general independence of the packages themselves I'm asking whether other people in this situation incorporate all of their packages into the same project and whether they include the project file itself in version control. – engil Oct 26 '12 at 16:48
  • Since you can't merge or diff .dtsx files in any useful way, just consider them to be binary files. That means SVN (or whatever) is still useful for version history and tagging/branching, but how to use those features is nothing to do with SSIS specifically. As for the VS files, that has been [answered already](http://stackoverflow.com/questions/72298/should-i-add-the-visual-studio-suo-and-user-files-to-source-control). – Pondlife Oct 26 '12 at 16:53

1 Answers1

2

Since your question has "AnkhSVN" in the title, I'm assuming you're using that.

If so, then yes, I highly recommend include your VS project files in SubVersion and bind them in BIDS / SSDT to SVN. That way you can "open project from source control" instead of local, and you can also do recursive check-ins at the project level.

I also highly recommend you standardize project creation by creating a "one project per application" rule. Letting people just cowboy their own one-off projects for package modification is, IMHO, silly and unproductive.

I think the biggest challenge for us is adding packages to projects in a "no-diff" environment like SSIS. Every time you open a data flow in an SSIS package, the file gets checked out and modified and so does the project file. People usually just blindly check in these "no-change" changes. So you get scenarios like:

  1. Alice adds a package to a project and checks it in.
  2. Meanwhile, Bob opens a package's data flow task just to check its source query, it checks out the project file.
  3. He checks in his change, it gives him a conflict with Alice's check-in, he just chooses use local.
  4. Now Alice's package is in no man's land, checked in but not in the project. Watch out for that deployment ...

Anyway, you can mitigate this obviously with some guidelines and discussions. I would also encourage you have some sort of de facto "gatekeeper" of SVN, because it will get messy and you'll need periodic cleanups of source control anyway.

At only 20 packages and what sounds like only intermittent package modification, you're probably not needing branching, but I'd at least read up on it. I think branching is something a team grows into once they start stepping on each other's toes a lot - kind of a judgment call when to enact it, although I would encourage your developers to use it if they feel comfortable with it.

Kyle Hale
  • 7,912
  • 1
  • 37
  • 58
  • Thanks kthejoker - this is basically what we ended up going with, at first we were just storing the dtsxes directly but we've switched over to including the VS project files – engil Dec 07 '12 at 17:16