这是我在过去一个月中两次遇到的事情，我甚至不确定如何将其表达为Google查询。

我实际上正在使用SVN进行所有操作，但是看来这应该是一个普遍的版本控制问题。

我们有两个项目，其中一个项目依赖于另一个项目的某些代码。由于API问题，在产品之间建立某种形式的链接并不实际(我不想配置所有非编码器的机器来实现此目的)。

我想，如果将共享代码的副本放入目录结构中，最终将覆盖SVN使用的所有配置文件。这意味着从属项目目录中的版本将不再能够更新。

例如：

项目#1需要使用类MyExampleClass，但是，MyExampleClass是定义为项目#2的一部分并由项目#2所需要的东西。

几年来，我们已经在实践中使用svn:externals指向共享代码。我们在使用它时遇到了一些有趣的问题，您可能应该考虑一下。这是我们拥有的结构：

项目中include和src中的common目录包含引入公共库的外部定义：

我们遇到的问题是多方面的，但与项目不断变化时标记和分支源代码有关。如果您想拥有可复制的版本，我在上面显示的外部定义存在一些非常严重的问题：

使用svn copy进行分支时，将逐字复制外部，因为它们实际上只是附加到对象的属性。其他一些svn命令(commit，checkout和export)实际上会解释属性。标记项目时，您确实要一直保留项目的状态。这意味着您必须将外部组件"固定"到特定修订版，因此您需要更改外部组件定义以显式引用所需的修订版(例如，"lib1 -r42 http://.../common/lib1/trunk/src")。这解决了问题的一个方面。

如果必须维护公共代码的多个不兼容分支，则必须指定要显式地与(可能是)修订一起的哪个分支。

不用说，这可能有点令人头疼。幸运的是，有人在Subversion领域写了svncopy.pl脚本来自动处理一些混乱。我们仍然(过去)一直在努力解决在现场部署的产品中支持这一问题的困难，这些产品具有一堆共享代码，并且可以随时在现场提供三个不同版本的授权。

如果您确实选择了这条路线，那么请务必考虑如何随着项目的发展和变化而保持联系。我们发现，花一点时间思考一个流程将在这里大有帮助。

查看svn:externals

外部人员，但请注意以下问题：

将外部更新更新到某个日期

将所有共享文件放在一个项目或另一个项目中的单独文件夹中。然后使用外部引用该文件夹。
将来自同一文件夹中不同位置的文件混合在一起是一个坏主意。

svn：externals将允许您在目录级别引入文件。像：

然后在Proj2中，您可以svn：externals Proj1，最后得到：

现在，如果要在1个文件夹中包含2个项目的文件，例如：

那我不认为SVN支持该功能。

但是，我与其他源代码管理工具一起使用，可以让您将单个文件从一个项目"链接"到所需的任何位置(特别是Borland StarTeam)。