我在我工作的公司里是一个单人乐队。我开发了一个Rails应用程序供公司内部使用。从项目开始以来，我已经使用SVN进行源代码控制，并完成了大部分（但不是全部）在trunk中的开发。偶尔，当我做了非常重大的改变时，我已经分支并在完成后将更改合并回来。一切都很典型。
但是，我所做的那些“重大变化”都没有触及过数据库迁移。它们一直是视图/控制器的东西。
在这种情况下，使用一个开发框，我如何解决我可能会或可能不会保留的迁移和各种数据库更改？我不想记得在将分支丢弃之前将所有迁移恢复到分支的开头，如果它不起作用的话。
我曾考虑建立特殊的开发环境和数据库（app_branch而不是app_development），但这似乎与实验开发倾向于依赖的“易分支”概念有很大关系。
这种情况有最佳做法吗？在这种情况下，其他人在做什么？
我努力保持我的开发数据库“可以删除”。如果我失去了一切 - 没什么大不了的。我的迁移已准备好从头开始重新构建它，并且总是有一个脚本，其中包含种子/测试数据。我想这不是特别聪明。
如果我需要一个新的数据库工作分支，我会检查它，删除，创建，耙，然后播种。我想我会写一个脚本来完成它，因为当我去adandon分支时，我将不得不从主干再次经历相同的过程。
确保schema.rb文件处于版本控制中。这样，当您切换分支时，您可以删除数据库，然后根据需要执行rake db：schema：load。
另外，你真的应该切换到Git。这将使分支管理比SVN容易得多。 （我从两个项目的经验来讲。）
好吧，如果你想拥有不同的模式，你需要多个数据库。 “简易分支”通常是指源控制，而不是数据库。据我所知，没有简单的方法来分支数据库，就像你将分支，比如git。
我们管理dev / production分支的一件事是在database.yml文件中检查当前的git分支。如果当前分支是生产，我们使用一个数据库，否则我们使用我们的dev数据库。类似的东西：
<% if 'git branch' =~ /^\* production/
db = 'production_database'
else
db = 'development_database
end %>
development:
database: <% db %>
注意，'production_database'指的是生产模式的本地版本，而不是实时生产数据库。
我写了一个脚本来处理这个确切的问题。它基于git，但您可以轻松地将其更改为适用于svn：
https://gist.github.com/4076864
给定一个分支名称，它将：
我发现自己一直在我们的项目中手动执行此操作，所以我认为自动化该过程会很好。
如果我正在创建一个您正在进行重大更改的分支，则可以在创建迁移之前创建数据库的副本，然后在分支内更改database.yml的development部分。单独保留:production部分，然后在将分支合并回主干时，确定要保留哪个版本的数据库以供将来开发。
我们使用功能发布来完成此操作我将拥有版本1,2,3的本地数据库，如“db_v1”，db_v2“等。当我们浏览版本时，每个后续开发分支在database.yml中进行编辑，而主干保留在最后一个版本上以修复错误。