从具有完整历史记录和共享文件的 Visual SourceSafe 迁移
我们目前在工作中使用 SourceSafe，我真的很想放弃它。我的老板原则上同意这一点，只要我们能保留我们的整个历史。我的第一个方法是研究 SVN 以及迁移到那里的方法。但我发现SVN不支持共享文件。
A：有没有好的RCS支持共享文件？
或者我是否必须找到一种方法来说服我的老板放弃该特定功能。显然，大多数系统都会有解决方法，但这对我来说已经是一个更困难的销售。
B：如何将完整的版本历史迁移到新的 RCS 中？
显然是自动化的，并且是在 Windows 上运行的东西。我还有兴趣了解与各个迁移工具相关的注意事项和问题。
谢谢。
- 理想情况下，我想对我的老板说：“看这个工具可以接管我们整个版本历史的每个细节，并且运行得比 VSS 好得多”。
- 如果不满足的话，它应该是：“看这个工具会比 VSS 更好地工作。共享文件的工作方式会略有不同，但可以支持我们所有的需求。”
- 如果不满足的话，我将不得不继续我的消耗战用常规武器对抗VSS...
We are currently using SourceSafe at work and I would really like to move away from it. My boss is ok with that on principle, provided we can take our whole history with us. My first approach was to look at SVN and ways to migrate there. But I discovered that SVN does not support shared files.
A: Is there a good RCS that supports shared files?
Or do I have to find a way to convince my boss to let go of that particular feature. Obviously there will be workarounds for most systems but that would already be a much harder sale for me.
B: How can I migrate the full version history into the new RCS?
Obviously automated and something that runs on windows. I'd also be interested to learn about caveats and problems associated with individual migration tools.
Thank you.
- Ideally I would like to go to my boss and say: "Look this tool can take over our whole version history with every detail and will run much better than VSS".
- Failing that it should be: "Look this tool will work much better than VSS. Sharing files will work slightly different but can support all our needs."
- Failing that I'll have to continue my war of attrition against VSS with conventional weapons...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议将存储库从 VSS 迁移到 Team Foundation Server (TFS)，这是一个顺利且轻松的过程使用捆绑的 VSSConverter.exe 工具与 TFS。它还会跨越您的 VSS 历史记录。
您可以删除共享文件并使用分支来代替，这更加有用和强大。
I can recommend migrating a repository from VSS to Team Foundation Server (TFS) it's a smooth and painless process using the VSSConverter.exe tool bundled with TFS. It also moves across your VSS history.
You can drop shared files and use branching instead, which is much more useful and powerful.
答：您可能想看看 Source Gears Vault。我从未在愤怒中使用过它，但它看起来是唯一与 VSS 具有相似外观和感觉的东西。
B. Vault 可能再次成为您的最佳选择。 TFS 的 VSS 转换器可以，但是您的大多数标签可能不会被迁移。至于其他版本控制系统我不确定。
所以避难所会遇到第一名，让老板高兴。我从未使用过它，所以它可能不是很好，但它被称为 VSS，没有损坏。我认为他们提供了试用版，所以我会下载并玩一玩。但它是一种商业产品，因此如果您需要免费（如啤酒）工具，那么这可能不适合您。
如果你想多做一点，做第二点，那么你会考虑 SVN、TFS、git 或 Mercurial。所有这些都与 VSS 有很大不同，并且都有自己的小怪癖。
从 VSS 迁移到任何其他版本控制系统都会很痛苦。除了 Vault 之外，没有任何东西可以完全复制 VSS 的行为方式。
另一位发帖者建议去 TFS。我刚刚将 100 个左右的 VSS 存储库迁移到 TFS，在我看来，这是一个更好的产品。话虽如此，将会涉及很多学习和规划。
VSS 使用了许多其他系统中不可用的约定，因此您需要退后一步，看看为什么要做这些事情，而不是如何做。一旦您弄清楚为什么使用共享和固定等功能，您就可以计划如何使用您选择的版本控制系统的功能来替换 VSS，以获得相同的结果。
如果像我一样，您在一家大多数开发人员仅使用 VSS 进行源代码控制的公司工作，那么您还必须考虑到他们需要某种培训。我发现 VSS 毒害了我们的思想，我们的开发人员和配置经理在理解分支和合并代码时遇到了真正的困难。
至于历史记录，即使您选择的新工具很可能会迁移完整的历史记录。您仍然需要注意，迁移后您可能无法使用任何共享、Pin 或标签。在许多情况下，我们认为最好的选择是“获取”已知有效的代码版本并进行迁移。在这些情况下，VSS 存储库设为只读，以便在需要时历史记录仍然可用。
以上所有内容均基于我自己从 VSS 迁移到 TFS 的经验，但我怀疑它适用于您将遇到的任何其他版本控制系统。无论您决定使用哪种工具，祝您好运！
A. You might want to take a look at Source Gears Vault. I've never used it in anger but it looks to be the only thing out there that has a similar look and feel to VSS.
B. Once again Vault is probably your best option. VSS converter for TFS does, however it's likely that most of your labels won't get migrated. As for other version control systems I'm not sure.
So Vault will meet number 1, keep the boss happy. I've never used it so it might not be very good, but it's billed as VSS without the corruption. I think they offer a trial version so I'd download it and have a play. It is a commercial product though so if you have a requirement for a free (as in beer) tool then this might not work for you.
If you want to go the extra mile, and do number 2 then you're looking at SVN, TFS, git or Mercurial. All of these are very different from VSS and all of them have thier little quirks.
Migrating to any other version control system from VSS is going to be painful. There isn't anything out there, other than perhaps Vault, which completely replicates the way VSS behaves.
Another poster has suggested going to TFS. I've just migrated 100 or so VSS repositories to TFS and in my opinion it's a much better product. Having said that, there will be a lot of learning and planning involved.
VSS uses a lot of conventions that aren't available in other systems, so you need to take a step back and look at why you do stuff and not how. Once you've figured out why you use features such as sharing and pinning, then you can plan how you'll use the features of whichever version control system you pick to replace VSS, to get the same results.
If like me, you work for a company where the majority of developers have only ever used VSS for source control then you also have to factor in that they will require some sort of training. I've found that VSS poisons the mind, and our developers and configuration managers have had real difficulties in getting their heads around branching and merging code.
As for the history, even though your new tool of choice may well migrate the full history. You still have to be aware that any Shares, Pins or Labels will probably not be available to you post migration. In a number of instances we decided that the best option was to "get" a known valid version of the code and migrate that. In those instances the VSS repositories were made read only so that the history was still available if required.
All of the above is based on my own experiences migrating from VSS to TFS but I suspect that it applies to any of the other version control systems you will come across. Whichever tool you decide to use, good luck!