Linking and unlinking would be fine if it automatically loaded the ConfigurationOptions.xml and the filter.scpf.

Would love to see true integration with Git (Github, Stash, Bitbucket) the way Bamboo does it perhaps where I could select a drop-down of branches and tags available to build against and selecting one would "refresh" the instance. Migration scripts would ideally to be in place for the underlying DML.

Just hoping to see migration and true branch support for Git - however it ends up looking!

Unfortunately branching does not currently work with migration scripts.

Currently I am using Mercurial as my source control and it would be very helpful if I had the ability to create a new branch on the check-in. It would also be helpful if I could switch what branch I was on inside of Management Studio.

I trying to incorporate SQL Source Control to my existing TFS database. I tried using "Link to a database already in source control", but I receive the error: "The URL needs to be a directory which contains a project file named RedGate.ssc". How do I create this file if I can't connect to the TFS source? Please let me know.

@David - the best would to be able to branch, switch and merge directly from within SQL Source Control (branching would be optional as that is probably as easy to do from within the source control provider). This would be without the need for us to have multiple databases registered (one for each branch). I think that it is possible with current Red Gate software at the moment because SQL Compare Pro and SQL Data Compare Pro can work on the scripts folders generated by SQL Source Control. To do a merge from a feature branch to trunk you'd switch the database to trunk then fetch the branch to a working folder and use SQL Compare Pro to synchronise from the working folder database to the database in SSMS.

Writing to the working folder as well as the source control provider wouldn't be very useful on its own. The bit that we are missing is *reading* from the working folder because that is what we need to do if we do the merge using the source control provider's tools so that we can test the merged database before we commit it to the database. I think that reading from source control and a working folder would be tricky as you'd have to do the merge when you pull from source control to the working folder and then get those changes to SQL Source Control. I don't think that's how you want to do it as it would be very likely that the source control provider's merge would produce code that wouldn't execute on the SQL server (for example, you often need to manually insert commas after a merge)

Of the two options that you gave, I think that providing a quick way of syncing the two branched databases in SQL Source Control without the need for SQL Compare would be the best.

@Steve - If we provided an option on the commit tab to write to a working folder as well as to commit directly to source control, would that help? Or would it be more useful if we provided a quick way of syncing the two branched databases in SQL Source Control without the need for SQL Compare. Which of these would solve your problem the best?

@David - that would work but it isn't as convenient as if the source control provider did the merging. Also, we don't have SQL Compare Pro licences for the whole team. Some only have SQL Source Control.

I've tried using a blank SQL Source Control config file and that might do the trick. With a blank file, the commit changes button just writes the changes to SVN's working copy and the get latest button reads from SVN's working copy. This allows all branching, switching and merging to be done in SVN and the merge can be tested by pressing the get latest button in SQL Source Control.

This also means that we need to commit our changes using SVN rather than SQL Source Control but that has the advantage of being able to commit the database changes at the same time as the application changes that use them which is a bonus, in my opinion.

@Steve - As your database is effectively the working copy in SQL Source Control the analogy would be the ability to merge from a private branch database to the trunk database. Would it work for you to maintain two dev databases, linking to your branch and trunk respectively, and use SQL Compare Pro to push the changes to your trunk branch before committing to source control?

I've been playing around with database branching with Mercurial and it works quite well - much better than SVN which is the source control we normally use.

The workflow for this is similar to the one in my previous comment but you can commit to your local repository without affecting anybody else and push to the central repo once the changes are tested:

1. Create branch 1 from default
2. Amend branch 1
3. Commit branch 1
4. Update to default branch
5. Merge branch 1 to the working copy
6. Commit default branch
7. Test merged code (after running Get Latest in SQL Source Control)
8. Push merged code to central repo

Also, switching branches is much easier in Mercurial. You switch the working copy and then run Get Latest in SQL Source Control. No need to attach and detach.

A big difference between how SQL Source Control works for SVN and Mercurial is that you attach to the working copy for Mercurial but you attach directly to the repository in SVN. This makes it harder to do the merge and test it with SVN.

I think that SVN support could be improved by adding the ability able to attach to a working copy instead of the repo itself. It's possible that user could do this themselves by adding a custom config file but I've not looked into this.

Hi,

SQL Source Control cannot execute the correct workflow for branching/merging even when using another SVN client to do the branch and merge. You need SQL Compare / SQL Data Compare to assist.

The correct workflow for SVN would be (ommitting connecting and fetching databases in SQL Source Control):

1. Branch DB/trunk -> DB/branches/1
2. Amend DB/branches/1
3. Commit DB/branches/1
4. Switch to DB/trunk
5. Merge DB/branches/1 to DB/trunk's working copy
6. Test merged code
7. Commit merged code to DB/trunk

It falls down in step 6 - there is no way to test the merge without committing it to SVN then getting the changes in SQL Source Control. Obviously, committing an untested merge is bad practice.

To do this without committing to SVN you would need to use SQL Compare to deploy the changes in the working copy to your development database so that you can test the merged database.

Steve

Hello mattb308,

Your second paragraph sounds like a different suggestion. You may want to vote/comment on "working with multiple dbs at the same time" at http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/458069-work-with-multiple-databases-at-a-time.

In addition to adding branching/merging support within the SQL Source Control interface (as opposed to manually managing it via TSVN) it will be important to include the equivalent of a SWITCH command to facilitate quickly moving between different branches. The current process works but it is laborious.

Also, it would be nice if there was a construct that would allow you to place multiple databases in the same branch (trunk) so they are versioned together. The current isolation per-database increases work effort when you're dealing with several databases that represent a cohesive unit of deployment and are logically versioned together.

I wonder if git (http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/537681-add-git-support?ref=title) would be a better way of resolving this?

We have multiple clients with different version of the database at different points. We need to be able to manage the merging and branching fairly easily. While that can be partly done within SVN, the ability to switch branches at least based on the database you are working on would be very helpful. Say you have basedb, client1 and client2 database. basedb can stay the latest, but client1 and client2 would be branches off basedb. We could then use the SVN tool itself for the merging and other branching, but at least we have some ability there.

SQL Source Control does not have the ability to right click on a db and branch or merge yet. :-)

Neil makes a good point that you can do this with TSVN, but there is a slight catch. In order for the branch to work in SQL Source Control, you must first link the db to the repository that you are branching from. Make sure the db is up to date with repository right before it was branched by getting latest. Then, unlink your db from this SVN repository on the SQL Source Control Setup tab. Then, "link to a db already in source control..." on the setup tab and copy and paste in the URL to your branched location. (The directory you link to needs to contain the RedGate.ssc file in order for SQL Source Control to setup the link correctly.)

Surely I can use TortoiseSVN (or any other similar tool) to manage branching and merging?

My team has the same issue. Several Developers working independently and commiting changes to subversion at different times. Looks like you always have to be in synch with what is in subversion before applying changes. There does not appear to be a merge to resolve conflicts like TortoiseSVN.

Developers can apply changes to the central db and then one person commit the changes, but that loses the ability to track who actually made the modification.

We currently don't support SQL 2000. If this is something you need, please vote/comment at http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/456019-support-sql-server-2000.

I have the same database with slightly different code for SQL 2000 (yes SQL 2000) and SQL 2008.