从 Visual SourceSafe 迁移到 SVN 时有哪些障碍和危险？
客户仍然使用 Visual SourceSafe，但在展示了 VSS 的众多危险和缺陷后，他们决定从 VSS 迁移到 SVN Subversion。
首选似乎是 Tortoise SVN 和 AnkhSVN（不错的选择？）。 此处描述了迁移辅助工具。该项目包含两个网站、一些Web应用程序、几个控件和函数库。
在我看来，“扫描所有与VSS相关的”，然后“在 SVN 中导入”是正确的选择。但世界并不完美。需要注意哪些问题，采取哪些措施才能使这一过程顺利进行？是否有我们应该注意的典型 SVN for .NET 问题？
编辑：是否也可以以某种方式迁移 VSS 历史记录，或者我们应该仅将其视为一个新的开始？
A client still uses Visual SourceSafe, but after showing the numerous dangers and deficiencies of VSS, they've decided to migrate from VSS to SVN Subversion.
The choice-to-be seems Tortoise SVN with AnkhSVN (good choice?). A migration aid is described here. The project contains two websites, a few web applications, several control and function libraries.
It seems to me that a "sweep all VSS related" and then "import in SVN" is the way to go. But worlds aren't perfect. What are the problems we should watch out for and what measures can we take to have this process run smoothly? Are there typical SVN for .NET issues that we should be aware of?
EDIT: is it possible somehow to migrate the VSS history too, or should we consider this a new start only?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
几年前我们进行了相同的迁移，并对结果非常满意。和 Pino 一样，我推荐 Tortoise SVN。 AnkhSVN 似乎对我们来说效果不佳。我不知道迁移历史的实用方法。
我们遇到的主要问题是由于 Subversion 本身的性质造成的，而不是迁移造成的。我们遇到的问题是：
We made the same migration a few years ago and were very pleased with the results. Like Pino, I recommend Tortoise SVN. AnkhSVN didn't seem to do work well for us. I don't know of a practical way of migrating the history.
The major problems we encountered were due to the nature of Subversion itself and not with the migration. The problems we encountered were:
有多种工具可以为您迁移历史记录。几年前，我们使用 VSS2SVN 来执行相同的步骤。
您可以并排使用多个 Subversion 客户端。我认识的几乎每个 Windows Subversion 用户都使用 TortoiseSVN，并且为了在 Visual Studio 中集成，您可以使用 AnkhSVN（自 AnkhSVN 2.0 起用于 VS 2005+ 的免费、完整的 SCC 提供程序）和 VisualSVN（商业；使用 TortoiseSVN 及其自己的扩展并提供类似 SCC 的功能） VS 2003+ 中的功能）。
我建议还安装一个普通的命令行 SVN 安装以供脚本使用。
有关 VisualSVN 和 AnkhSVN 之间的更多比较，请参阅 AnkhSVN 与 VisualSVN。但请注意，所有客户端（TortoiseSVN、AnkhSVN、VisualSVN）只是相同库的外壳，因此您可以随时在它们之间切换。
There are several tools that can migrate history for you. We used VSS2SVN a few years ago to make this same step.
You can use multiple subversion clients side by side. Almost every Windows user of Subversion I know uses TortoiseSVN and for integration in Visual Studio you can use AnkhSVN (Free, full SCC provider for VS 2005+ since AnkhSVN 2.0) and VisualSVN (Commercial; Uses TortoiseSVN with its own extensions and provides SCC-like features in VS 2003+).
I would recommend also installing a normal commandline SVN install for use by scripts.
See AnkhSVN vs VisualSVN for more comparisons between VisualSVN and AnkhSVN. But note that all the clients (TortoiseSVN, AnkhSVN, VisualSVN) are just a shell over the same libraries, so you can switch between them any time you like.
到目前为止，最大的障碍是教育开发人员了解使用源代码控制系统的差异。
签出编辑签入编辑合并提交：
刚接触 SVN 的开发人员必须熟悉两个开发人员同时对文件进行更改的想法，并且他们稍后会合并这些更改。 VSS 用户通常不知道这种类型的源代码控制是可能的，并且肯定对这种转换感到不舒服。
项目绑定到文件系统绑定：
VSS 通常在项目和解决方案级别管理源代码控制。项目绑定到源代码管理，项目中发生的任何更改也会发生在源代码管理中。在SVN中，没有这样的绑定。所有更改都在文件系统中进行跟踪，这意味着当您将新文件添加到项目中时，您还必须将该文件添加到源代码管理中。
仅出于这个原因，我建议花时间为您的项目设置持续集成服务器。这将快速拾取提交中遗漏的任何文件，并防止其他开发人员进行签出并收到构建错误的尴尬场景，因为文件在您的项目中被引用，但不存在于源代码管理中。
分支：
虽然你可以在VSS中执行分支，但我很少看到有人使用它，因为设置分支、切换到分支然后在完成后合并分支是相当棘手的它。使用 SVN 不需要分支，但这可能是您进行切换的重要原因之一。开发人员需要适应在合适的地方创建分支并将它们重新合并到主干中的想法。
如果您的开发人员已经熟悉使用 SVN，那么您应该不会遇到任何问题。如果没有，他们可能需要一些指导来让他们自己看到 SVN 的优势，并希望最终喜欢使用它。
By far the biggest hurdle will be educating the developers to the differences in using the source control systems.
Checkout Edit Checkin to Edit Merge Commit:
Developers new to SVN have to be comfortable with the idea of two developers making changes to a file at the same time, and that they will merge those changes later. VSS users are typically unaware that this style of source control is even possible and most certainly don't feel comfortable with the transition.
Project Binding to File System Binding:
VSS typically manages source control at the project and solution level. The project is bound to the source control and any changes which happen to the project also happen to the source control. In SVN, there is no such binding. All changes are tracked at the file system, meaning that when you add a new file to your project, you also have to add the file to the source control.
For this reason alone, I recommend investing the time to set up a continuous integration server for your projects. This will quickly pick up on any files which are missed from commits and prevents the awkward scenario of other developers doing a checkout and getting build errors because a file is referenced in your project, but is not present in your source control.
Branching:
Although you can perform branching in VSS, I've rarely seen anybody use it because it's quite tricky to set up a branch, switch to a branch and then merge the branch when you're finished with it. Branching isn't required to use SVN, but it's probably one of the big reasons you'd make the switch. Developers need to get comfortable with the idea of creating branches where it seems appropriate and re-merging them into the Trunk.
If your developers are already comfortable with using SVN, you shouldn't have any problems. If not, they may need a bit of guidance to make them see the advantages of SVN for themselves, and hopefully end up enjoying using it.
第一个建议：保留备份:)
第二：Tortoise SVN - Defo 是 Windows 机器的最佳选择，并且与 Visual Studio 集成（通过 VisualSVN）
Number one bit of advice: Keep a backup :)
Number two: Tortoise SVN - Defo the way to go for a windows machine, plus integrates with Visual Studio (Via VisualSVN)