有一些可用于PHP的Rails风格的迁移项目. http://code.google.com/p/mysql-php-migrations/是一个很好的例子.它使用迁移文件的时间戳,这有助于分支之间的冲突.

这种系统的一般问题：
当开发分支机构A检出并且想要检查分支机构B时,
B可能有新的迁移文件.这很好,迁移到较新的内容是直截了当的.

如果分支A具有较新的迁移文件,则需要向下迁移到最近的共享修补程序.如果分支A和B具有明显不同的代码库,则可能需要进一步迁移.这可能意味着：检查B,确定共享的修补程序号,检出A,向下移动到此修补程序.这必须从A完成,因为实际应用的补丁在B中不可用.然后,检出分支B,并迁移到最新的B补丁.从B到A再次反向过程.

拟议制度：
当向上迁移时,而不是仅仅存储补丁版本,将整个补丁序列化在数据库中以备以后使用,尽管我可能只需要使用down()方法.
更改分支时,将已运行的修补程序与目标分支中可用的修补程序进行比较.确定运行补丁的db表和目标分支中的补丁之间的最近的共享补丁(或者最大的差异,可能是ID或散列).还可以查找两个分支之间的一些共享补丁下的新的或缺少的补丁.

自动合并到最近的共享修补程序,使用db表存储down()方法,然后合并到branche的最新补丁.

我的问题是：
这个系统是否太疯狂和(或)充满后果,打扰发展？我对数据库模式版本控制的经验仅限于PHP autopatch,它是一个up() – 仅需要具有顺序ID的文件名的系统.

更新,2年后

这是一个老帖子,但我想提到,在开发过程中,我已经放弃了迁移,因为它们不必要地复杂且容易出错.

相反,我使用构建脚本来：

>清除数据库,
>创建模式,
>添加已知的应用程序数据(实际内容),和
>添加夹具数据(开发内容).

当更改分支或从其他开发人员接收更新时,您可以使用一个命令完全重新加载数据库以进入已知状态.

生产服务器仍然需要数据库修补程序,但是这些修补程序仍然需要手动创建.