从Source Depot迁移到SVN
自从我在 Microsoft 工作以来，我就有了一个用于版本控制的本地 Source Depot 存储库。 最近，我一直想迁移到 SVN 并随身携带更改历史记录，但似乎没有迁移到 SVN 的脚本。
因为有不少微软人在这里闲逛，所以我想我应该来这里尝试一下。 我基本上是在寻找一个简单的迁移脚本来为我处理事情。
除此之外，欢迎任何其他建议来帮助我继续前进。 仅供参考，Source Depot 基于 Perforce，我尝试了 perforce 迁移工具，但没有成功。
I have had a local Source Depot repository for version control since my days at Microsoft. Lately, I've been wanting to migrate to SVN and take the change history with me but there seems to be no script to migrate to SVN.
Since there are quite a few Microsofties who hang out here, I thought I'd try here. I am basically looking for an easy migration script that would take care of things for me.
Barring that, any other advise is welcome to get me on my way. FYI, Source Depot is based off Perforce and I have tried the perforce migration tools without any success.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Source Depot 有类似 Perforce 的命令行吗？
大约一年前，我使用 Python 脚本通过几个步骤将我的家庭 SCC 仓库从 Perforce 迁移到 SVN。 虽然我不再有剧本，但它非常简单，是一天下午写的。
基本上，脚本从第一个强制变更列表开始，并按顺序运行所有这些变更列表。 它将同步到每个更改列表并将文件拆分为编辑/添加/分支列表。 然后，这些文件将被复制到 SVN 路径，并使用适当的命令进行更新/添加/分支。 然后将使用原始更改列表中的注释来提交它们。
这为我提供了 Perforce 仓库的完整 SVN 镜像，其中保留了所有历史记录/评论和分支信息。 我只有一个用户（我！），但支持多个用户并不困难。
我什至考虑过让脚本更改系统时钟，以便历史日期正确，但这似乎不值得。 对我来说，历史记录和分支/标签信息是最重要的。
Does Source Depot have a command line similar to Perforce?
About a year ago I moved my home SCC depot from Perforce to SVN in a few steps using a Python script. While I no longer have the script it was pretty simple and written one afternoon.
Basically the script started at the very first perforce changelist and ran through them all in sequence. It would sync to each changelist and split the files into edit/add/branch lists. These files would then be copied to the SVN path and updated/added/branched using the appropriate commands. They'd then be committed using the comment from the original change-list.
This gave me a complete SVN mirror of my Perforce depot with all history/comments and branch info retained. I only had one user (me!) but it wouldn't be difficult to support multiple usees.
I even toyed with the idea of having the script change the system clock so that the history dates would be correct but it didn't seem worth it. For me the history and branch/tags information was the most important thing.
不久前，我的公司有一位承包商拜访我们进行信息会议，内容涉及将所有源代码和版本历史记录从 MKS 迁移到 SVN。 事实证明，在迁移过程中保持版本历史记录完整实际上非常困难，因为它们都有自己的方法来存储该历史记录。 我从那次访问中得到的收获是，有一些昂贵的第三方工具可以进行迁移，但它们很难找到，而且实际上并不是那么好。
我们最终决定，对于大多数项目，我们会硬着头皮使用现有源代码创建新的源代码控制项目，丢失新软件的版本历史记录并将旧软件备份在磁盘上。
当然，我们的情况略有不同，因为我们的基本版本历史记录的格式不同（我的是 MKS，你的是 SD）。 但是，我不相信找到一个神奇的脚本来转换它并不容易。 我可能是错的，但无论如何，这就是我从我们的会议中得到的结果。
My company had a contractor visit us for an info session a while back about migrating the all of the source and version history from MKS to SVN. It turns out that it's actually very difficult to keep the version history intact through a migration process because they all have their own methods for storing that history. What I took away from that visit was that there are some expensive third party tools that will do migrations, but they are hard to find and really aren't all that great.
We ended up deciding that for most projects, we would bite the bullet and just create new source control projects with the existing source, losing the version history for the new software and keeping the old ones backed up on disk.
Granted, our situations differ a little in that our base version histories are not in the same format (mine is MKS, yours is SD). But, I don't believe it will be easy to find a magic script for converting it. I could be wrong, but this is what I got out of that meeting that we had, anyway.
也许我误解了你的问题，但是是什么阻止你从 Source Depot 中完整检出代码，然后将其检入 Subversion 呢？
除非您还打算导入已设置的任何用户/组控件，在这种情况下，签出/签入将无法完全实现这一点。
Perhaps I'm misunderstanding your issue, but what prevents you from doing a full checkout of the code from Source Depot, and then checking it into Subversion?
Unless you also mean to import any user/group controls that were setup, in which case a check-out/check-in wouldn't completely accomplish that.