Integrate into existing 3+ year changeset history

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

Integrate into existing 3+ year changeset history

Postby PDinCA » Wed Oct 06, 2010 9:13 pm

I have a Subversion source control repository and Tortoise SVN Client setup that dates back at least 5000 changesets and has all database artifacts within it - 8 databases.

I have NO desire to lose the "diff" capabilities that are available via a web UI (using TRAC, which gives visibility to all Users outside SSMS), so I cannot simply add the databases to SVN via SQL Source Control - I will lose all traceability to ongoing and implemented projects.

I've not seen any reference to being able to integrate SQL Source Control into an existing well-defined workflow.

Is there a workaround I can avail myself of, or are there any plans to support my needs?

Thanks in anticipation (and hopes).
PDinCA
 
Posts: 517
Joined: Mon Jul 25, 2005 11:42 pm
Location: Costa Mesa, CA, USA

Postby Chris Auckland » Fri Oct 08, 2010 9:36 am

Thanks for your post.

It really depends on the format of the objects that reside in your existing repository.

If the scripts have been created using SQL Compare, then it may be possible to add the necessary config files to use the existing repository with SQL Source control. However, if the scripts have been created by another method, then it is probably unlikely that you can use SQL Source control with them.

Can you confirm how the current repository has been set up?
Chris
Chris Auckland
 
Posts: 757
Joined: Tue Oct 24, 2006 2:12 pm
Location: Red Gate Software Ltd.

Postby PDinCA » Fri Oct 08, 2010 5:24 pm

SQL Compare has never been used here - I'm the new DB guy at the new company and am bringing in RG's tools having had great success with them for the last 5+ years.

I'll have to run the issue of "starting over" by my Director - it would be very sad to be unable to use integrated source control as the existing "maintain a set of source folders by database and object type and a separate set of 'release' folders" is a TOTAL pain! Deployment is nightmare and I've already found dozens of inconsistencies between Production and other environments that should, ostensibly, be the same.

The objects are in SVN as simple "create <<object>> ..." scripts, EXACTLY taken from SSMS' "script object as 'CREATE'" right-click or "script database". Why there would be an obstacle to making SQL Source Control able to simply recognize these items seems to be a question begging an answer...
PDinCA
 
Posts: 517
Joined: Mon Jul 25, 2005 11:42 pm
Location: Costa Mesa, CA, USA

Postby Chris Auckland » Fri Oct 15, 2010 4:52 pm

Sorry for the delay.

Unfortunately we're not going to be able to support scripts that haven't been created using SQL Source control, or SQL Compare.

We may be able to read the scripts in, but we would end up writing them out to new files based on our own naming convention. This would end up loosing the history.

SQL Source control (and SQL Compare) only support scripts that are organised in a certain way. For example, if SSMS writes out objects like triggers to separate files, then we wouldn't be able to handle it.

We could add support for scripts created by SSMS, but as there are so many different configurations you can use, it would be a nightmare to support all of them. So far there doesn't seem to be much call for supporting SSMS scripts.

Sorry I can't really give you a workaround for this.
Chris
Chris Auckland
 
Posts: 757
Joined: Tue Oct 24, 2006 2:12 pm
Location: Red Gate Software Ltd.

Postby PDinCA » Fri Oct 15, 2010 5:22 pm

Thanks for taking the time to consider the problem I'm facing.
PDinCA
 
Posts: 517
Joined: Mon Jul 25, 2005 11:42 pm
Location: Costa Mesa, CA, USA


Return to SQL Source Control 1

Who is online

Users browsing this forum: No registered users and 1 guest