有人成功地将 VSS 2005 迁移到 SVN 吗？
我最近一直在使用 SVN，并开始喜欢它的强大功能和用户体验，并且我们可以将它与我们的错误跟踪系统结合起来以简化每个人的生活。 因此，我们决定将 VSS 2005 设置迁移到 SVN，而我现在开始摆脱困境了。
似乎有很多工具声称能够完成从 VSS 2005 到 SVN 的迁移，但我不知道哪个是最好的，或者哪个将为我提供最完整的过渡。 我需要一个能够迁移完整历史记录的工具，而不仅仅是从 VSS 签出并签入 SVN。
我发现 Polarion SVN Importer 看起来既强大又高度可配置，但是，我无法让该死的东西工作，它抱怨它无法从 VSS 中的 $/ 中提取文件列表。 如果我运行相同的命令，它会手动出错，一切似乎都运行正常，所以我无法弄清楚。
是否有人成功地将其源代码从 VSS 2005 迁移到 SVN？如果是，您使用了哪些工具以及您的发现是什么？ 任何警告或陷阱都是最有用的，所以要知道任何有用/令人惊讶的东西，或者令人失望的东西，或者只是简单的歪曲的东西。
I've been playing around with SVN for the last little while and have come to love its power and user experience and that we can tie it into our bug tracking system to simplify everyone's lives. So it's come to the time that we've decided to migrate our VSS 2005 setup across to SVN and I am now coming unstuck.
It seems there are a number of tools out there that claim to be able to complete the migration from VSS 2005 to SVN, but I can't figure out which is the best one or which will provide me with the most complete transition. I need one that will migrate the full history across rather than just checking out from VSS and checking into SVN.
I found Polarion SVN Importer which looks both powerful and highly configurable, however, I can't get the damn thing to work, it complains that it can't pull the file list from $/ in VSS. If I run the same command it's tripping up on manually, everything seems to run okay, so I can't figure it out.
Has anyone successfully migrated their source from VSS 2005 to SVN and if so what tools did you use and what were your findings? Any caveats or gotchas would be most useful so know as well as anything that was useful/surprising or was a let down or just plain misrepresented.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
尝试 Codeplex 上 VssMigrate 的最新主干（控制台应用程序）修订版，以重新排序您的历史记录并从 VSS 存储库重新生成变更集。 它还会根据您的修订签入时间正确排序。
http vssmigrate.codeplex.com/SourceControl/changeset/view/16890
我希望这会有所帮助。 可能需要对 $/ 导入进行一些调整。
PS 历史记录可以帮助您一步知道该归咎于谁，而不必根据导入来发现注释是否正确，所以我发现它相当有用。 在旧代码中发现错误时，拥有它比没有它好得多。
PPS 您甚至可以使用新版本的 VssMigrate 将修订版本重新导入到 Subversion 存储库，然后在上次导入修订版本之后合并所有修订版本。 唯一的缺点是每个人都必须从存储库中重新检出，因为修订数量将大大减少。 基本上，执行新的迁移； svnadmin dump active 以前从 rev migerated+1 迁移的存储库作为增量，然后 svnadmin 加载到新迁移的存储库中。
Try the lastest trunk (console app) revision for VssMigrate on Codeplex to re-order your history and re-generate changesets from your VSS repository. It will also order your revisions correctly based on the time they were checked in.
http vssmigrate.codeplex.com/SourceControl/changeset/view/16890
I hope this helps. It might take some tweaking on the $/ import.
P.S. the history helps you know who to blame in a single step rather than having to discover if the annotation is correct based on an import, so I find it rather useful. Much better to have it than not have it when finding bugs in older code.
P.P.S. You can even use the new version of VssMigrate to re-import the revisions to a subversion repository and then merge in all of the revisions after the last import revision from your previous revision. The only downside is that everybody will have to get a fresh check-out from the repository because the number of revisions will be dramatically reduced. Basically, perfom a new migration; svnadmin dump active previously migrated repository from rev migrated+1 as incremental and then svnadmin load into the newly migrated repository.
大约一年前，我尝试了 Polarion 和 vss2svn。
我们在VSS中有很多年的代码，我发现在所有的配置和测试之后我对结果并不完全满意，这个过程漫长而脆弱，最后决定从全新导入最新代码开始。
去年我有几次去寻找古老的历史，但并不是那么多。 重新开始的另一个好处是你的新 SVN 存储库将会非常快！
I tried both Polarion and vss2svn about a year ago.
We had many years of code in VSS, and I found that after all of the configuration and testing that I was not entirely satisfied with the results, the process was long and fragile, and in the end, decided to just start with a clean import of the latest code.
There have been a few times over the last year where I went looking for old history, but not really that much. Another plus of starting fresh is that your new SVN repository will be very fast!
我上次尝试这个是几年前的事了。 由于 VSS 文件格式没有记录，为了获得完整的历史记录，第 3 方转换程序必须使用 VSS 的 API 来获取每个文件的每个版本。 我让这个转换在周末进行，看看它完成了多少（百分之几），并计算出需要几周的日历时间才能完成（我们有多年的历史）。
因此，我们决定仅将最新代码的快照移至新的版本控制系统中，并保留 VSS 数据库的存档以备历史之需。
The last time I tried this was years ago. Because the VSS file format wasn't documented, to get a complete history the 3rd-party conversion program had to use VSS's API to get each version of each file. I let that conversion run over the week-end, saw how much it had accomplished (a few percent), and calculated that it would take weeks of calendar time to complete (we had years of history).
We therefore decided to move only a snapshot of the latest code into the new version control system, and kept an archive of the VSS database for history's sake.
与这个问题类似 - 不同的迁移，但我也认为尝试捕获历史是浪费精力/时间。
从 SourceSafe 迁移的最佳方式是什么到 ClearCase？
Similar to this question - different migration, but I also think it is a waste of effort/time to try to capture the history.
What's the best way to migrate from SourceSafe to ClearCase?
几个月前我成功地将VSS 2005迁移到SVN。 我使用了“VssMigrate.Tim2”工具，该工具现在显然在 CodePlex 上为 vssmigrate。 它运行良好，没有出现重大问题。 看起来修订和时间戳的顺序确实不像我预期的那样，但这没什么大不了的。
编辑：使用 vssmigrate，您可以选择迁移特定的 VSS 路径（例如 $/GroupA/ProjectB），这减少了单独迁移的时间并使整个过程不那么脆弱。 尽管我们在 VSS 中只有大约六个月的数据，但我并没有发现这个过程太长。 我在一个周末成功完成了迁移和 Apache+SVN 设置。 根据 VSS 存储库的大小，您可能需要创建多个 SVN 存储库而不是庞大的单个存储库。
我非常高兴我们放弃了 VSS，尽管配置 Apache+SVN 并不是太有趣（反复试验）。 我正在考虑 Git 或 Mercurial，但当时都没有可靠的 TortoiseXxx 工具或 VS SCC 插件。 尽管现在 Google 代码 已支持 Mercurial 和 TortoiseHg 看起来不错，我很想尽快尝试 Mercurial。
I successfully migrated VSS 2005 to SVN several months ago. I used the "VssMigrate.Tim2" tool which is apparently on CodePlex now as vssmigrate. It worked fine with no major issues. It did seem like the revisions and timestamps weren't ordered quite like I expected, but it wasn't a big deal.
EDIT: With vssmigrate, you can choose to migrate a specific VSS path (e.g. $/GroupA/ProjectB) which reduces the time for individual migration and makes the overall process less fragile. I didn't find the process too long although we only had about six months of data in VSS. I managed to complete the migration and Apache+SVN setup over a weekend. Depending on the size of your VSS repository, you may want to create multiple SVN repositories instead of a massive single repository.
I am extremely glad we moved away from VSS, although configuring Apache+SVN wasn't too much fun (trial and error). I was considering Git or Mercurial, but neither had a reliable TortoiseXxx tool or VS SCC plugin at the time. Although now that Google code has supported Mercurial and TortoiseHg looks good, I'm tempted to try Mercurial soon.