我的开发团队使用Visual Source Safe进行版本控制；这个选择最初是由于成本和它与Visual Studio的紧密集成。随着我们的代码库增长，Source Safe开始显示出其局限性，我们正在考虑转移到另一个解决方案。讨论的选项包括Team Foundation Server、Subversion、Git和Mercurial。我们主要是一个数据店，因此对我们来说另一个主要因素是能够轻松地对SQL Server 2005/2008项目进行版本控制。这是使用Source Safe的好处之一，也是使用Team Foundation Server的好处之一——与Microsoft SQL Server Management Studio的集成。我想知道是否有人在Subversion、Git或Mercurial中对SQL Server进行过版本控制，并且能够为每个系统提供一些实质性的优缺点，以及您如何实施它们。
8个回答
5
我的真实回答是，如果可以避免的话，请不要将数据库工具和SCM集成。尽可能使用文件系统。这是另一层集成，会带来痛苦。小型独立工具比庞然大物更好。
我们在以下方式下同时使用Subversion和SQL 2005：
- 我们仅使用TortoiseSVN，没有任何VS/SSMS集成。 - 我们有一个“自动化一切”的原则，因此我们从不依赖GUI工具完成工作。 - 我们将所有脚本与代码放在SVN中。代码、模式和脚本一起进行版本管理。 - 模式更改按应用程序顺序编号，例如000-create-table-users.sql。我们记录每个环境中部署的最大脚本编号。每个脚本执行到下一个数据库版本号的迁移。当我们部署时，我们检出源代码并运行所有脚本，从最后一个版本号到最高版本号。 - 任何非模式脚本（存储过程/视图）都是幂等的（可以多次执行且结果相同）。它们通过我们编写的nant插件应用。每次部署时都会替换它们。不要忘记刷新视图！ - 我们尽可能避免使用任何脚本，因为我们使用NHibernate，所以脚本版本控制问题较少。
从这个结构中，我们可以在任何机器上的任何时间点重新创建环境和数据库，这很重要。
但是，我们不会将其用于单元测试-我们依靠NHibernate模式生成在SQLite数据库上完成此操作。
我们遇到的唯一负面点是确保开发人员遵守流程。“牧猫”是一个非常恰当的描述。
我们在以下方式下同时使用Subversion和SQL 2005：
- 我们仅使用TortoiseSVN，没有任何VS/SSMS集成。 - 我们有一个“自动化一切”的原则，因此我们从不依赖GUI工具完成工作。 - 我们将所有脚本与代码放在SVN中。代码、模式和脚本一起进行版本管理。 - 模式更改按应用程序顺序编号，例如000-create-table-users.sql。我们记录每个环境中部署的最大脚本编号。每个脚本执行到下一个数据库版本号的迁移。当我们部署时，我们检出源代码并运行所有脚本，从最后一个版本号到最高版本号。 - 任何非模式脚本（存储过程/视图）都是幂等的（可以多次执行且结果相同）。它们通过我们编写的nant插件应用。每次部署时都会替换它们。不要忘记刷新视图！ - 我们尽可能避免使用任何脚本，因为我们使用NHibernate，所以脚本版本控制问题较少。
从这个结构中，我们可以在任何机器上的任何时间点重新创建环境和数据库，这很重要。
但是，我们不会将其用于单元测试-我们依靠NHibernate模式生成在SQLite数据库上完成此操作。
我们遇到的唯一负面点是确保开发人员遵守流程。“牧猫”是一个非常恰当的描述。
- Chris Smith
4
您需要的是Visual Studio Team System 2008数据库版（代号“DataDude”）。
它允许您以令人惊叹的方式对数据库对象进行版本控制（例如升级客户站点到特定版本，或回滚到以前的版本而不破坏任何数据）。
请查看Gert Drapers的博客上的功能，从此帖子开始。
或者如果您喜欢播客，请听DotNetRocks与Chris Sells在第494集中的演讲。
我不知道在使用DataDude时是否局限于TFS作为源代码控制，但它是Visual Studio系列中未被充分宣传的成员。
- David White
1
1"DataDude"是Visual Studio 2008及其后续版本的附加版本，它不依赖于TFS（实际上只是一种项目类型）。您可以在此处阅读更多相关信息：https://dev59.com/6HVC5IYBdhLWcg3w1E3w - RobS
1
在我看来，Git和Mercurial是你应该考虑的唯二选择，其他两个太过老式。现代SCM应该像Git一样处理分支。
关于Git和Mercurial的比较，请参见以下链接： http://rg03.wordpress.com/2009/04/07/mercurial-vs-git/, http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn。
我没有使用过SSMS SCM集成，但据我所知，除了TFS之外，提到的这些系统都没有。我不认为这是一个劣势 - 例如，Git GUI是一个非常方便的工具，你会发现它比集成更加愉快。至少在我的情况下，从带有VS集成（使用Ankh）的SVN转移到没有任何集成的Git时是这样的...
- synhershko
1
如果你认为分布式版本控制系统是正确的选择，Mercurial可以与VisualHG集成。我们在我们的工作室中使用它来管理C++/C#项目，它运行得足够好。另一方面，我从未使用过任何“完整”的集成，所以我很高兴使用资源管理器扩展和/或命令行进行详细的VC工作。
- Macke
1
我们现在已经为SQL Source Control添加了VSS支持，它与SSMS集成，为数据库开发提供完全集成的源代码控制。要尝试此功能，请访问：
http://www.red-gate.com/MessageBoard/viewtopic.php?t=12265
- David Atkinson
0
TFS缺少VSS的一些功能，尤其是关键字扩展。如果您没有在源文件中嵌入修订关键字信息，则不应该担心。
- David R Tribble
0
可能有很多选择 - SQL Server管理工具 (SSMS) 支持与任何Microsoft源代码控制接口 MSSCCI提供程序集成。因此，您可以将搜索范围扩大到具有MSSCCI兼容提供程序的源代码控制系统。
在SSMS中，检查工具->选项->源代码控制，以查看安装在您的系统上的提供程序插件。
例如，Team Foundation Server与SQL Management Studio的集成是由TFS MSSCCI提供程序提供的。我认为有一个CVS/Subversion的提供程序(“Aigenta Unified SCC”)等等。
至于优缺点列表，我认为只要有兼容的提供程序，您就可以向更广泛的观众打开问题。我的主要经验是VSS、TFS和Subversion。这确实取决于您的团队和环境。您能否详细说明一下您的环境？
例如：
- 您有兴趣建立CI（持续集成）吗？
- 自动化构建/自动化版本控制？
- 支持多个环境？
- 配置管理？
- 您的团队规模是多少？可能会有很多合并/分支等操作吗？
- 您已经有一个缺陷跟踪系统了吗（您可以将工作项/缺陷跟踪作为TFS推出的一部分）？
- RobS
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接