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).
An Beta release of SQL Source Control is now available, which supports Migrations for Mercurial.
You can download at http://www.redgate.com/migrations
We have also released a beta for SQL Compare. which is aware of Migrations v2 scripts and will apply these to target databases.
NOTE: This is a Beta release and is not fully tested or functionally complete yet. It would be great if you could try it in a test environment and let us know about your experiences so we can fix any issues and try to make any updates you need before the full release.
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 firstname.lastname@example.org 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.
Mike Lehner commented
+1 for git migrations. We could have used Mercurial for our DB projects but our other departments (Web) are already working with Git and after using it seems to fit better into our workflow.