从Visual SourceSafe迁移到SVN时有哪些障碍和危险？

Question

客户端仍然使用Visual SourceSafe，但在显示VSS的众多危险和不足之后，他们决定从VSS迁移到SVN Subversion。

对于AnkhSVN来说，选择似乎是Tortoise SVN（不错的选择？）。移民援助is described here。该项目包含两个网站，一些Web应用程序，几个控件和函数库。

在我看来，"sweep all VSS related"然后“导入SVN”是要走的路。但世界并不完美。我们应该注意哪些问题以及我们可以采取哪些措施来使这一过程顺利进行？是否存在我们应该注意的典型SVN for .NET问题？

编辑：是否有可能以某种方式迁移VSS历史记录，或者我们是否应该将此视为新的开始？

Answer 1

几年前我们进行了相同的迁移，并对结果非常满意。像皮诺一样，我推荐Tortoise SVN。 AnkhSVN似乎对我们没有好处。我不知道迁移历史的实际方法。

我们遇到的主要问题是由于Subversion本身的性质而不是迁移。我们遇到的问题是：

1. 学习使用合并而非独家结帐。
2. 了解Subversion中没有删除任何内容。因此，向安装程序添加先决条件然后删除它不会减小存储库的大小。我们当前的备份大小为4GB +压缩。
3. 备份需要一些脚本，不像SourceSafe是一个简单的文件副本。 svnadmin hotcopy 为我们工作。
4. 我们发现每个用户拥有不同分支的“用户分支”对我们不起作用。我们现在为所有用户提供了一个中继。
5. 可以在没有评论的情况下进行更改。您可以使用预提交挂钩修复此问题。
6. 放弃MS Visual Studio集成。没有听起来那么糟糕。

Answer 2

有几种工具可以为您迁移历史记录。几年前我们使用VSS2SVN来实现同样的目标。

您可以并排使用多个subversion客户端。我知道Subversion的几乎每个Windows用户都使用TortoiseSVN，并且为了在Visual Studio中集成，你可以使用AnkhSVN（自AnkhSVN 2.0以来VS 2005+的免费，完全SCC提供者）和VisualSVN（商业;使用TortoiseSVN及其自己的扩展并提供类似SCC的VS 2003 +中的功能。

我建议安装一个普通的命令行SVN安装供脚本使用。

有关VisualSVN和AnkhSVN之间的更多比较，请参阅AnkhSVN vs VisualSVN。但请注意，所有客户端（TortoiseSVN，AnkhSVN，VisualSVN）只是相同库的shell，因此您可以随时在它们之间切换。

Answer 3

到目前为止，最大的障碍是教育开发人员使用源控制系统的差异。

Checkout Edit Checkin to Edit Merge Commit：

SVN新手的开发人员必须对两位开发人员同时更改文件的想法感到满意，并且他们稍后会合并这些更改。 VSS用户通常不会意识到这种风格的源代码控制甚至是可能的，而且大多数情况下肯定不会对转换感到满意。

项目绑定到文件系统绑定：

VSS通常管理项目和解决方案级别的源代码管理。项目绑定到源代码控制，项目中发生的任何更改也会发生在源代码管理中。在SVN中，没有这样的绑定。在文件系统中跟踪所有更改，这意味着当您向项目添加新文件时，还必须将文件添加到源代码管理中。

仅凭这个原因，我建议您花时间为项目设置持续集成服务器。这将快速获取提交中遗漏的任何文件，并防止其他开发人员执行签出和获取构建错误的尴尬场景，因为项目中引用了文件，但源控件中不存在该文件。

<强>分支：

虽然你可以在VSS中执行分支，但我很少看到有人使用它，因为设置分支，切换到分支然后在完成分支时合并分支是非常棘手的。使用SVN不需要分支，但这可能是您进行切换的重要原因之一。开发人员需要熟悉在合适的地方创建分支并将它们重新合并到主干中的想法。

如果您的开发人员已经习惯使用SVN，那么您应该没有任何问题。如果没有，他们可能需要一些指导，让他们自己看到SVN的优势，并希望最终享受使用它。

Answer 4

一点建议：保持备份:) 第二名：Tortoise SVN - 改进了Windows机器的方式，再加上与Visual Studio（通过VisualSVN）的集成