有一些可用于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年后
这是一个老帖子,但我想提到,在开发过程中,我已经放弃了迁移,因为它们不必要地复杂且容易出错.
相反,我使用构建脚本来：
>清除数据库,
>创建模式,
>添加已知的应用程序数据(实际内容),和
>添加夹具数据(开发内容).
当更改分支或从其他开发人员接收更新时,您可以使用一个命令完全重新加载数据库以进入已知状态.
生产服务器仍然需要数据库修补程序,但是这些修补程序仍然需要手动创建.
这个项目就是这样的：
http://github.com/Billiam/MySQL-PHP-AutoMigrations
需要一些爱(准确的评论,单元测试,实际的错误测试),但似乎对我来说现在很好.
这是http://code.google.com/p/mysql-php-migrations/的叉子,包括上面的想法,还有一些其他的小东西.
向下迁移是通过在数据库中保存的方法完成的,以便文件更改(如在分支之间切换时)不会影响向下迁移.
增加了两个功能：
>一个魔术’自动’功能,可以处理迁移到最旧的共享迁移,然后直到迁移目录中的最新迁移.
>’提出’功能,显示自动实际做什么.
然而,仍然非常乐意听到这种方法的潜力(甚至是预期的)陷阱.