Integrate into existing 3+ year changeset history

PDinCA

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

Chris Auckland

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?

PDinCA

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

Chris Auckland

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.

PDinCA

Thanks for taking the time to consider the problem I'm facing.