从 Visual SourceSafe 迁移到 SVN 时有哪些障碍和危险? [英] What are the hurdles and dangers when migrating from Visual SourceSafe to SVN?
问题描述
客户仍在使用 Visual SourceSafe，但在展示了 VSS 的众多危险和不足之后，他们决定从 VSS 迁移到 SVN Subversion.
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.
未来的选择似乎是带有 AnkhSVN 的 Tortoise SVN(不错的选择?).此处描述了迁移辅助工具.该项目包含两个网站、几个网络应用程序、几个控件和函数库.
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.
在我看来，清除所有与 VSS 相关的" 然后在 SVN 中导入"是要走的路.但世界并不完美.我们应该注意哪些问题，我们可以采取哪些措施来使这个过程顺利进行?是否有我们应该注意的 .NET 问题的典型 SVN?
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?
是否也有可能以某种方式迁移 VSS 历史记录，还是应该仅将其视为一个新的开始?
is it possible somehow to migrate the VSS history too, or should we consider this a new start only?
推荐答案
我们几年前进行了相同的迁移，对结果非常满意.和 Pino 一样，我推荐 Tortoise SVN.AnkhSVN 似乎对我们来说效果不佳.我不知道迁移历史的实用方法.
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.
我们遇到的主要问题是由于 Subversion 本身的性质而不是迁移.我们遇到的问题是:
The major problems we encountered were due to the nature of Subversion itself and not with the migration. The problems we encountered were:
- 学习使用合并结账而非排他结账.
- 了解到 Subversion 中不会删除任何内容.因此，添加具有先决条件的安装程序然后将其删除不会减小存储库的大小.我们当前的备份大小是 4GB 以上的压缩包.
- 备份需要一些脚本，不像 SourceSafe 是一个简单的文件副本.svnadmin hotcopy 为我们工作.
- 我们发现每个用户都有不同分支的用户分支"对我们不起作用.我们现在为所有用户提供了一个中继.
- 可以在没有评论的情况下提交更改.您可以使用预提交挂钩解决此问题.
- 放弃 MS Visual Studio 集成.没有听起来那么糟糕.
这篇关于从 Visual SourceSafe 迁移到 SVN 时有哪些障碍和危险?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
