与 DVCS 结合使用的 SQL 迁移工具
大多数（如果不是全部）现有迁移工具都认为迁移历史是线性的。因此，当您创建新的迁移时，您将获得版本 42 或其他版本，然后每个人都可以在收到您的更改后更新到此版本。
问题是，如果您使用 DVCS，两个人可能会同时拥有版本 42。这意味着解决冲突将变得非常重要，甚至会带来痛苦。 :)
所以我的问题是 - 我应该推出自己的系统还是有什么东西在野外？最好简单，对*nix友好。我计划主要将其与 mysql 和 postgresql 一起使用。
Most (if not all) of existing migration tools think that migration history is linear. So when you create new migration, you get version 42 or whatever, and then everybody can update to this version after receiving your changes.
The problem is that if you are using DVCS, two people could have version 42 in the same time. Which means that conflict resolving will become sufficiently non-trivial to be painful. :)
So my question is - should I roll my own system or is there anything in the wild? Preferably simple, friendly to *nix. I'm planning to use this mostly with mysql and postgresql.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
在 Rails 中，处理此问题的方法是将日期附加到文件的开头，格式为 YYYYMMDDHHMMSS_migration_descriptor.rb。
然后，它通过跟踪版本号来跟踪表中已应用哪些迁移。这允许您在版本号比最近更改“更低”的表上运行迁移，从而大大简化 DVCS 问题。
您可能没有使用 Rails，但我认为他们解决这个问题的方式非常好。您可以API 文档阅读有关 Rails 迁移的更多信息，或者Rails 指南。
In Rails, the way this gets handled is by appending the date to the beginning of the file, in the form of
YYYYMMDDHHMMSS_migration_descriptor.rb.It then keeps track of which migrations have been applied in a table, by keeping track of the version numbers. This allows you to run migrations on a table with a "lower" version number than the most recent change, thus greatly simplifying DVCS problems.
You might not be using Rails, but I think the way they solve this problem is pretty nice. You can read more about Rails migrations on the API docs, or on the Rails guides.