Provide tool to merge MigrationHistory
Using Migrations V2:
In one database, Developer A makes some changes, adds a Migration Script, and then checks in.
In a second database (linked to the same source control location), Developer B makes some different changes and adds a different, unrelated, migration script. Now, before B checks in, they want to get A's changes. They go to the "Get Latest" tab, and they see that the Redgate.MigrationHistory TVF has conflicts and needs to be merged.
The options are "Keep Mine" or "Take theirs", but neither of those will work because MigrationHistory needs to be merged. The "Merge" button won't work, because it only supports sprocs.
According to RedGate customer support, the way to fix this is:
you will have to manually merge these. First copy the syntax of your history, then unlink in Source Control and go into the repo browser and paste that into the repo sql script by hand.
This seems like a case where the SQL Source Control should help out more. Perhaps it should have a special UI to merge the MigrationHistory TVF. Or, maybe it could just merge it automatically.
Hi Wesley, First of all let me apologize for the cursory decline. We really appreciate the thought you have put into this and the time you’ve given it with support.
The reason we are not expecting to implement your request is that we are now taking a different approach with migrations. Please see http://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/2299881-migrations-support-for-git-mercurial for more information.
We would love to have you take a look at what we’re developing, though. Would you like to try out some merge scenarios with the new storage format?
Best regards,
Elizabeth Ayer
Product Manager, SQL Source Control
-
AdminElizabeth Ayer (Admin, Redgate) commented
Wesley,
You're right. Our plan had us changing the Migrations V2 documentation when the new Migrations itself got to beta. The idea was that you should actually have something in your hands at the time we officially switched advice.
This is clearly leading to some wasted effort on your part and ours, though, so I am revisiting the issue with the team this week. We'll see about getting those documentation changes made sooner rather than later. In the meantime, I'll square up the message with support.
When the SOC 5 beta first comes out, Migrations won't work yet with SQL CI, but we plan to add that in the course of the beta.
In the meantime, thank you very much for your patience and helpful approach.
-
Wesley Smith commented
Elizabeth,
Thanks for pointing out to me the change in direction you're taking with the approach to migrations. I've had lots of difficulty using the V2 beta approach, so overall I'm happy that you're taking a different approach. I do feel, though, that I've wasted a lot of time on the V2 beta approach, both in trying to get it to work, and also in creating reproducible test cases that demonstrate bugs that I've found in tools that relate to this feature.
I moved to the V2 migrations because I need to merge migrations from one branch to another, and because I want to use the SQL CI tools, and from what I understand, they require the use of the V2 migrations. The V2 migration stuff is clearly marked as beta everywhere, so I can't say I'm surprised that it's going away, but on the other hand, the DLM Automation Suite is a product that's not marked as beta and that I've paid for a license for, so that seemed to me to indicate that I could count on the V2 migrations being supported.
I think I'd feel better if your decision was more obvious - if you made it clear that V2 migrations were a temporary solution that were going away soon. For example, on pages such as https://documentation.red-gate.com/display/SOC4/Working+with+migration+scripts or https://documentation.red-gate.com/display/SOC4/Migration+scripts+V2+beta. Also, I've had several conversations with customer support where they seemed grateful to receive my bug reports on V2 features without ever mentioning that that wasn't the future of the product.
If the new approach will work with the SQL CI tools, then I'd be interested in trying out the new storage format - otherwise I'll probably continue to get by with the V2 support until the new approach is supported by the CI tools.