我正在寻找可以成功替代Microsoft Visual SourceSafe的修订控制软件。我花了很多时间重新研究这个问题，但最终没有找到合适的解决方案。为什么？因为VSS的共享文件似乎是一个独特的功能。
具体来说，共享文件是指映射到多个位置的单个文件。例如，当您想在不同项目中使用一个源代码文件时，只需将其拖放到您需要的任何项目目录中即可。然后有一个文件链接到几个目录。当sombody在任何这些项目中修改该文件时，所有其他项目都会将其更新为其主要版本。
SVN中的一个等效功能是svn：externals，它能够以两种方式共享文件：使用头版本或使用明确选择的版本。但是，无论我选择哪一个，结果都不同于VSS。因此，当我将一个外部文件附加到其头版本中的项目时，它几乎就像在VSS中一样。但是当我想要对我的项目进行历史性修订时，我总是得到外部文件的头部修订而不是适当的历史修改。它看起来像一个bug，但也许有一个原因SVN以这种方式工作。第二个选项是在选定的修订版中使用外部文件。但是当有人在任何地方修改它们时，必须在每个项目中手动更新这些文件。我们真的不想手动执行此操作。
Plastic SCM是我检查的第二个解决方案。恕我直言，这个系统很棒！精确而清晰的GUI和精彩的修订图，让您轻松处理分支和合并。与VSS相比，这真的吸引了我的注意力。但是让我们谈谈这个话题。 Plastic支持Xlinks（符号链接），但只能使用它们链接目录，而不能链接文件。更重要的是，没有选择共享头部修订版本（您必须明确选择特定版本）。
让我问你该怎么做。选择哪种软件可以提高我们的工作效率，同时又不失去共享功能？为什么这么不受欢迎？是否有不同的方法在项目之间共享代码？
答案 0 :(得分：1)
IMHO每个文件与共享位置的链接令人困惑，我认为这解释了为什么大多数SCM选择采用允许在目录级别共享的范例（如果有的话）。除了你带来的PlasticSCM的例子，我有git的经验，它提供了这个功能submodules，再次要求你将共享文件放在一个单独的目录中，并强制一个较少混淆的层次结构共享部分（子模块）与使用它的项目之间的关系。
不幸的是，你似乎爱上了一个没有多少需要或使用的功能。可能是您的需求如此独特。但是你应该仔细考虑你的要求是否确实是独一无二的，并且可能会为更主流的开发约定做出小小的牺牲（在这种情况下，将共享文件放在一个单独的目录中），这将允许你使用state-最先进的工具。