对于版本控制，我们目前使用Visual Source Safe并且正在考虑迁移到另一个版本控制系统（SVN，Mercurial，Git）。
目前我们非常重视Visual Source Safe的“共享”文件功能。这使我们可以在单个产品的设计和运行时之间以及多个产品之间共享代码。
例如：
**Product One**
- Design
Login.cpp
Login.h
Helper.cpp
Helper.h
- Runtime
Login.cpp
Login.h
Helper.cpp
Helper.h
**Product Two**
- Design
Login.cpp
Login.h
- Launcher
Login.cpp
Login.h
- Runtime
Login.cpp
Login.h
在此示例中，Login.cpp和Login.h包含我们所有项目所需的公共代码，Helper.cpp和Helper.h仅用于Product One。在Visual Source Safe中，它们在特定项目之间共享，这意味着无论何时在一个项目中更新文件，它们都会在与其共享的任何项目中更新。
这是一个简单的示例，但希望它解释了我们使用共享功能的原因：减少重复代码的数量，并确保在修复错误时，所有项目都可以自动访问新的固定代码。
在研究Visual Source Safe的替代品之后，似乎大多数版本控制系统都没有共享文件的想法，相反，他们似乎使用了子库的想法。 （https://www.mercurial-scm.org/wiki/subrepos http://svnbook.red-bean.com/en/1.0/ch07s03.html）
我的问题（在所有这些之后）是关于实现这一目标的最佳实践是使用其他版本控制系统？
我们应该重组我们的项目，以便不存在两个文件副本，而是使用include目录吗？ e.g。
第一产品
这仍然留下了如何处理Login.cpp和Logon.h
共享文件是否应该移动到自己的存储库然后编译成lib或dll？这将使错误修复更加耗时，因为必须编辑然后重建lib项目。
我们应该使用外部或子存储库吗？
我们应该将项目（即运行时，设计和启动器）合并到一个大型项目中吗？
任何帮助将不胜感激。我们感觉我们的项目设计是基于我们使用的工具而发展的，现在我们正在考虑切换工具，我们很难看到如何最好地修改我们的实践。
或者也许我们是唯一有这样做的人......？
此外，我们使用Visual Studio来完成所有工作。
感谢。
答案 0 :(得分：1)
我只能从SVN的角度讲，但是将多个项目中使用的文件存储在一个单独的模块中是很常见的（SVN具有模块的概念，我认为这就是你所指的sub的意思库）。
我这样做的方法是在一个单独的模块中签入多个项目所需的公共代码。如果您将此模块称为Design，而其他两个产品已作为ProductOne和ProductTwo检入SVN，那么您只需查看Design和{{1 }}}，make ProductOne依赖于ProductOne进行编译。
在Visual Studio中，工作空间称为解决方案，可以包含多个项目。因此，您可以将所有三个模块都作为项目，并使Design项目依赖于ProductOne项目。就这么简单。
答案 1 :(得分：0)
我过去曾从类似的情况（C ++，Visual Studio，VSS）迁移到svn。我们选择使用svn：externals在不同项目之间共享源代码。它工作，但它不是很漂亮。特别是对于分支和标签，这可能会变得非常痛苦。
我现在强烈建议将共享代码移动到一个单独的项目中，并在lib级别共享。如果仔细考虑开发和构建过程，调试和共享开发可以同样有效。此外，将共享代码移动到版本控制中的单独项目并不一定意味着它应该完全独立于代码的其余部分。这更多的是周围的流程和项目管理。另一方面，此方案允许独立维护库。在你目前的情况下，你甚至没有那个选择。
答案 2 :(得分：0)