这是我在过去一个月中遇到的两次，我甚至不确定如何将其称为Google查询。
我实际上正在使用SVN，但看起来这应该是一般的版本问题。
我们有两个项目，其中一个项目依赖于其他一些代码。由于API问题，在产品之间建立某种形式的链接并不务实（我不想配置所有非编码器的机器来使其工作）。
我想如果我将共享代码的副本放入目录结构中，我将最终覆盖SVN使用的所有配置文件。这意味着依赖项目目录中的版本将无法再更新。
例如：
项目＃1需要使用类MyExampleClass，但是，MyExampleClass是由Project＃2定义为部分和需要的东西。
答案 0 :(得分：14)
我们已经在实践中使用了svn:externals指向共享代码几年了。我们在使用它之前应该考虑一些有趣的问题。这是我们的结构：
root
+---common
| +---lib1
| | \---trunk
| | +---include
| | \---src
| \---lib2
| \---trunk
| +---include
| \---src
+---proj1
| \---trunk
| +---include
| | \---common
| \---src
| \---common
\---proj2
\---trunk
+---include
| \---common
\---src
\---common
项目中common和include中的src目录包含引入公共库的外部定义：
c:\dev> svn pget -v svn:externals proj1\trunk\src\common
Properties on 'c:\dev\proj1\trunk\src\common':
svn:externals : lib1 http://.../common/lib1/trunk/src
lib2 http://.../common/lib2/trunk/src
我们遇到的问题是多方面的，但与项目标记和分支有关，因为项目会随着时间的推移而变化。如果您想要具有可重现的构建，我在上面展示的外部定义有一些相当严重的问题：
trunk。使用svn copy进行分支时，外部会逐字复制，因为它们实际上只是附加到对象的属性。其他一些svn命令（commit，checkout和export）实际上解释了这些属性。标记项目时，您确实希望始终保留项目的状态。这意味着您必须将外部“固定”到特定修订版本，因此您需要将外部定义更改为显式引用所需的修订版本（例如，"lib1 -r42 http://.../common/lib1/trunk/src"）。这解决了问题的一个方面。
如果必须维护公共代码的多个不兼容分支，则必须明确指定（可能）修订版本所需的分支。
毋庸置疑，这可能有点令人头疼。幸运的是，有人在Subversion土地上写了svncopy.pl脚本来自动化这些混乱。我们仍然（而且一直）在一个现场部署的产品中遇到一些困难，这个产品带有一堆共享代码，并且在任何时候都可以在现场使用三种不同的版本。
如果您沿着这条路走下去，那么一定要考虑在项目发展和变化时如何维护这些联系。我们发现，在这里花一点时间考虑一个过程将会有很长的路要走。
答案 1 :(得分：11)
答案 2 :(得分：1)
将所有共享文件放在其中一个项目中的单独文件夹中，或者放在单独的文件夹中。然后使用externals引用该文件夹。 混合来自同一文件夹中不同位置的文件是个坏主意。
答案 3 :(得分：1)
外部，但要注意这个问题：
答案 4 :(得分：0)
svn：externals将允许您在目录级别引入文件。像：
Proj1\
File1
File2
Proj2\
File3
File4
然后在Proj2中你可以svn：externals Proj1，最后得到：
Proj2\
Proj1\
File1
File2
File3
File4
现在，如果您想将来自2个项目的文件放在1个文件夹中，如：
Proj2\
File1 <- from Proj1
File2 <- from Proj1
File3
File4
然后我认为SVN不支持。
但是，我使用过其他源代码控制工具，可以让你将一个文件从一个项目“链接”到另一个项目（特别是Borland StarTeam）。