有没有办法将带有 HISTORY 的 SourceSafe 迁移到 SVN 中？
有没有办法将带有 HISTORY 的 SourceSafe 迁移到 SVN 中？
理想情况下，我想使用 VisualSVN Server，但我真的不想丢失我的 SourceSafe 历史记录。 如果必须的话我会的。
Is there a way to migrate SourceSafe with HISTORY into a SVN ?
Ideally I'd like to use VisualSVN Server, but I don't really want to lose my SourceSafe history. If I have to I will though.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
很久以前（似乎）我尝试使用 vss2svn 将 SourceSafe DB 迁移到 subversion，但最后放弃。 有几个问题，IIRC：
因此，最终我们决定保持 SourceSafe DB 完整（只读），并将当前版本迁移到 subversion。 到目前为止，我们很少需要返回 SourceSafe 来检查某些内容。
希望这可以帮助。
顺便说一句：无论您使用 VisualSVN Server 还是直接使用 subversion（svnserver）都没有关系。 两种情况下的存储库格式相同。
A long time ago (it seems) I tried to migrate a SourceSafe DB to subversion using vss2svn, but finally gave up. There were several problems, IIRC:
So finally we decided to keep the SourceSafe DB intact (read-only) and just migrate the current version into subversion. So far, there were very few occasions where we had to go back to SourceSafe to check something.
Hope this helps.
BTW: it does not matter whether you use VisualSVN Server or subversion directly (svnserver). The repository format is the same in both cases.
尝试使用 vss2svn 脚本。
或者 vss2svn 项目。
Try the vss2svn script.
Or the vss2svn project.
我成功转换了我们令人讨厌的 VSS 数据库，包括历史记录。 我在博客中讲述了这次经历 < 转换亮点是：
“所有转换工具还要求源 VSS 数据库在转换之前清除损坏。事实证明，这比您想象的要困难得多且耗时得多在数据库副本上运行 VSS 分析工具会显示数百个损坏，并且如果不蓝屏运行该工具的计算机，就无法运行完成。
为了解决此问题，我们通过删除未删除的目录来减少副本数据库。不幸的是，VSS 会在删除过程中报告每个损坏，导致用户必须无意识地单击这些消息框才能继续该过程，
我们使用工具 VSS2SVN 创建导入的转储文件 。进入颠覆。”
I successfully converted our nasty VSS database including history. I blog about the experience here. The conversion highlight is:
"All of the conversion tools also required the source VSS database be clean of corruption before the conversion. This turned out to be much harder and time consuming than you might think. Running the VSS Analyze tool on a copy of the database showed hundreds of corruptions and would not run to completion without blue screening the computer it was running on.
To get around this we reduced the copy database by deleting the directories that we didn’t want to convert. Unfortunately VSS will report each corruptions during the deleting process causing hundreds of message boxes that the user must mindlessly click for the process to continue.
Once that point was reached, we used the tool VSS2SVN to create dump files that were imported into Subversion."
我们使用 Polarion SVN Importer 将 VSS 迁移到具有完整历史记录的 SVN。
We used Polarion SVN Importer to migrate VSS to SVN with full history.
是的，请使用 Codeplex 上的 VSS2SVN 项目。 我已经更新了它，以便在迁移到 SVN 时保留历史记录、评论、作者和日期属性。 需要更长的时间，但我认为这并不重要，因为这不是你每天都会做的事情。
它还可以选择使用超过特定日期的 VSS 文件更新存储库，以便您可以稍后更新初始转储。
Yes, use the VSS2SVN project on Codeplex. I've updated it so it maintains history, comments, author and date properties when migrating to SVN. Takes a bit longer, but I don;t think that matters as its not something you do everyday.
It also has an option to update the repository with files from VSS past a certain date, so you can update an initial dump later on.
在我的公司，我反复尝试使用 vss2svn 将（大）SourceSafe 存储库迁移到 Subversion。 我什至在代码页支持方面做出了小小的贡献（我们有希腊语的文件名）。 如果我没记错的话（这发生在去年春天；即 2009 年），我们的主要问题（使我们最终放弃迁移的问题）是在存储库的想要和不需要的部分之间交叉链接/移动的永久删除的文件被阻塞迁移。
我的建议：如果您无法在完全分析存储库中完成此操作，请不要浪费更多时间。 只需画一条线并从一个新的颠覆存储库开始。
注意：在 SourceSafe 中永久删除文件会使该文件完全无法恢复，这与 CVS/SVN 类型的源代码控制系统（我想还有其他源代码控制系统）完全不兼容。
At my company I tried repeatedly to migrate a (big) SourceSafe repository to Subversion with vss2svn. I even caused a small contribution regarding codepage support (we had filenames in Greek). If I remember correctly (this happened last spring; i.e. of 2009), our main problem (the one that made us finally dismiss migration) was that permanently deleted files that were cross-linked/moved between wanted and unwanted parts of the repository were blocking the migration.
My suggestion: If you can't do it in a fully Analyzed repository, don't waste more time. Just draw a line and start with a new subversion repository.
Note: Permanently deleting a file in SourceSafe makes the file totally unrecoverable, which is something entirely incompatible with CVS/SVN-type source control systems (and, I suppose, other source control systems as well).
我公司开发了一个Source Safe到Subversion的迁移工具：
http://www.abstrakti.com/Products/Krepost
该工具是在遇到问题后开发的当我们必须迁移客户的存储库时，我们可以使用其他所有工具。 此外，这是唯一可以将 SourceSafe 标签导入 SVN 的工具。 此外，它还能够处理大多数 SourceSafe 存储库损坏，并为不想花几天时间调试 C# 代码的用户提供轻松的迁移。
如果您有任何问题，请告诉我，我很乐意为您提供帮助。
埃里克.
My company has developed a Source Safe to Subversion migration tool:
http://www.abstrakti.com/Products/Krepost
This tool was developed after having problems with every other tool, when we had to migrate a customer's repository. Also, this is the only tool that can import SourceSafe labels into SVN. Additionally, it's able to deal with most of SourceSafe repository corruptions, and offers a painless migration to users who don't want to spend a few days debugging into C# code.
Let me know if you have any problems, I'll be glad to help you.
Eric.
我使用 vss2svn 脚本成功地将几个源安全存储库迁移到 SVN 中。 我的建议是，分成小块来做——我们有很多小项目和几个中等规模的项目，它们都成功地转移到了 SVN。
我遇到了几个问题：
I successfully managed to migrate the several source safe repositories into SVN using vss2svn script. My suggestions are, do it in small chunks - we had a lot of little projects and a couple of medium side projects, which all managed to be moved successfully to SVN.
I had a couple of problems: