Migrations support for Mercurial
It seems that right now migrations only support SVN, TFS and Vault - none of which I'm willing to use anymore. Please consider prioritizing support for Git/Mercurial.
Allow HG Source control (Mecurial/Kiln) to create migration scripts. Changes generated do not always generate the correct SQL, so it would be good to be able to modify the SQL "generated" prior to committing (which I assume is done via Migration Scripts).
Migrations for Mercurial (migrations v2) can now be used throughout the delivery lifecycle with the latest versions of the Red Gate SQL tools. SQL Source Control, SQL Compare, SQL CI and Deployment Manager all use migrations v2 scripts if configured to do so.
NB. We’re still calling the migrations feature a beta feature within the products. This is because we are continuing to release user interface improvements and improve stability, and we do not yet consider the feature complete. However the core products have been through their full testing and release processes and are stable.
A frequent releases channel for SQL Source Control is now available, and it is this channel that contains the migrations v2 feature. This means you can evaluate the new migrations functionality without having to install a beta version of SQL Source Control, and you will benefit from the regular updates being made to SQL Source Control.
SQL Compare 10.6 (currently in beta) supports migrations v2 scripts. The migrations v2 feature must be enabled on the options tab. Migrations v2 are enabled by default in SQL CI (part of the SQL Automation Pack) and in Deployment Manager.
We’d really like to hear about your experiences so we can fix issues and try to make any updates you need before the final release.
Download links for SQL Source Control and SQL Compare with migrations v2 and, along with instructions on how to enable migrations v2 are on http://www.red-gate.com/migrations
Please note that if you have previously installed the standalone migrations v2 beta versions of SQL Source Control (version 3.9.x) or SQL Compare (10.9.x) you will need to uninstall these in order to install versions 3.6.×. and 10.6.×.
Josh Rogers commented
What is the status of this beta? We just purchased the Developer Bundle and we're eager to be able to use these migrations.
Peter van Rees commented
Can anyone from Redgate comment on the progress on this issue? We are using Hg and are forced to keep seperate SVN repos for the database projects only because of this issue not being solved....
You would make me very happy if this would work!
Damian Powell commented
"The [DVCS] issue is more challenging than we had anticipated, but we're completely committed to solving it as the highest priority for SQL Source Control."
Is it still highest priority? It's been a while. How about an update?
If supporting DVCSs with their non-linear histories is really difficult, why not release a half-way solution that will work with a DVCS provided it has a linear history? At the moment, we have SQL Source Control but really aren't getting the most out of it, even though our DB history is completely linear.
Adam Swann commented
You've likely got 9 new users on this end once you make this happen.
Jeff Jones commented
Good news, looking forward to using it.
Joe Kearney commented
Are there any updates to this? Any expected date of release? David, from your last comment it looks this might yet take some time – is that a fair prediction? Thanks
It's still very much on the forefront of our minds and we're still very committed to solving the problem of automating the generation of database changes. The differences between DVCS and "traditional" source control systems, particularly the non-sequential revision numbers, have a bigger architectural impact that we had first anticipated, which has meant a re-think on how we might implement our solution.
Jamie Clayton commented
Almost March 2013, 8 months after the August 2012 release date. Must be very close by now or has Red-gate forsaken this commitment?
Reuben Greaves commented
Any ideas on the anticipated release for this feature yet?
If the difficulty with this feature request has been determining what changes are already applied to the database and what changes still need applied, then I would find it acceptable to have a version tracking table on the database.
With that tracking table, would this feature be more straight forward?
Greg Engle commented
please add this support. The flexibility of being able to jump around from branch to branch in mercurial is priceless. This is a completely different mindset from SVN.
I should be able to start a feature branch, put it on hold and switch gears to another feature branch at anytime.
Hein Albrecht commented
I can confirm that we have put the wheels in motion and we're just beginning to completely understand the extent of DVCS and branching complexity. The issue is more challenging than we had anticipated, but we're completely committed to solving it as the highest priority for SQL Source Control.
John O'Brien commented
Any updates on this feature?
We only commmit. We don't do the push. However, you can edit the commandhooks xml file and make any custom changes to suit the behavior you're looking for. Please email email@example.com if you need help doing this.
Is it normal presently with Mercurial that when I commit changes in the Red Gate Window In SQL Server, the "phase" is at "draft" and it isn't pushed to the server? Is that a setting I forgot? If it's normal, than it would be a good thing to add it in the next release!!
Golden Tamarin commented
Based on the rate of grow. Git/Mercurial represent the future.
Migration support for Mercurial would be a very good choice.
git is a good version control system.
I like it ,and hope it can be supported earlier
The revised target is to get this out by the end of the year. Some unanticipated circumstances beyond the control of the project team have conspired against our earlier estimate. Our sincere apologies for the delay.
Would appreciate an update on release date for this feature.