2

Are there any tools/techniques available for Integrating SQL Code with Subversion for versioning?

Jags
  • 29
  • 1

4 Answers4

2

Yep, check out Red Gate's SQL Source Control for one option

AdaTheDev
  • 142,592
  • 28
  • 206
  • 200
  • Can I use SQL Source control for SVN - Subversion? – Jags Mar 07 '11 at 12:45
  • @Jags: yes. check the site provided which lists supported repositories – gbn Mar 07 '11 at 12:47
  • @Jags - yes, it supports SVN and TFS with support for more coming soon (Vault, Vault Pro, Mercurial, Perforce, CVS, Git, and Bazaar) - per: http://www.red-gate.com/products/sql-development/sql-source-control/features – AdaTheDev Mar 07 '11 at 12:47
0

In the IDE you can use SQL Source Control from Red Gate

Otherwise, you can script your objects into source-controlled folder. We use Red Gate for this (since before SQL Source Control was released)

Community
  • 1
  • 1
gbn
  • 422,506
  • 82
  • 585
  • 676
0

I like to separate code from data for this purpose. So Views, StoredProcs, Functions get version controlled like normal, but changes to tables, indices, data, are stored as incremental changes.

If you have the budget, VS2010 Team System is a nice option, as is RedGate Sql Source Control.

That said, it's not too hard to roll your own. You'll need two components:

  1. A script to pull all code objects from the DB to disk
  2. A script to deploy the code objects from disk to DB

I've some samples on how to do this at https://github.com/ScottWeinstein/PSIS

Scott Weinstein
  • 18,890
  • 14
  • 78
  • 115
0

I have an open-source (licensed under LGPL) toolset project which tries to address the issues related to proper DB schema versioning (and more), the bsn ModuleStore.

Basically, the standalone part of it scripts the SQL Server DB objects of a DB schema into files with a standard formatting applied, so that the file contents only changes if the object really did change (very much in contrast to the scripting done by VS, which scripts some scripting date etc. as well, marking all objects as changed even if they are in fact identical).

But the toolset goes beyond that if you use .NET: it allows you to embed the SQL scripts into the library or application (as embedded resources) and then have it compare the embedded scripts with the current state in the database. Non-table-related changes (those that are not "destructive changes" as per Martin Fowler's definition) can be applied automatically or on request (e.g. creating and removing objects such as views, functions, stored procedures, types, indexes), and change scripts (which need to be written manually though) can be applied in the same process as well; new tables are also created, optionally along with their setup data. After the update, the DB schema is again compared against the scripts in order to ensure a successful DB upgrade before the changes are committed.

Depending on how you want to access the database, the toolset offers does even more - it implements some ORM capabilities and offers a very nice and useful interface-based approach to invoke stored procedures, including transparent support for XML with native .NET XML classes and also for TVPs (Table-Valued Parameters) as IEnumerable<PocoClass>.

Lucero
  • 59,176
  • 9
  • 122
  • 152