如果我理解正确,您希望确保
foo
和
bar
共享同一个分支。
foo
是您的主项目,并且在某个地方有一个指向
bar
的
svn:externals
。 当您分支
foo
时,您希望确保
bar
使用相同的分支。 唯一的方法是使用根目录而不是项目根目录(像大多数网站一样)创建您的存储库,其中包含
tags
和
branches
目录。
然后,您可以使用相对外部引用从包含svn:external
的foo
目录指向bar
。 另外,如果使用相同的标签标记foo和bar,则foo和bar将维护它们之间的关系:
$ svn propset svn:externals ../../bar common
如果你的分支位于仓库的根目录下,那么
common
目录将指向与
bar
上的
foo
分支相同的分支。
svn:externals
的一个大问题是,如果你不小心,你会指向一个不断变化的链接目标目录版本。假设有人这样做了:
$ svn propset svn:externals /projects/bar/trunk common
在我的
foo
项目中,我发布并将
foo
拷贝到一个标签。然而,当某个人更新
bar/trunk
时,我打标签的
common
目录将被修改。这几乎使重新构建
foo
成为不可能。
当我使用
svn:externals
时,我总是确保链接到
bar
的已标记版本或特定修订版本;如果我链接到特定修订版本,我还会把 URL 锁定到该修订版本,以防有人决定删除我链接到的目录。
在 Subversion 中没有任何自动更新你的
svn:externals
属性的功能,但是你可以使用下列命令在目录树中搜索所有的 svn:externals:
$svn propget -v -R svn:externals .
我发现
svn:externals
通常比它的价值更麻烦。
相反,我只是将
bar
的构建对象或源代码的压缩副本存储在我的发布仓库中,并且作为我的构建过程的一部分,我会将对象或压缩的源代码从我的发布仓库中复制出来。
我使用Maven站点仓库(如Nexus或Artifactory)作为我的发布仓库,即使我不是在进行Maven项目,甚至不是在Java项目中工作。本地Maven仓库提供了上传和下载依赖包所需的所有工具,此外Maven还有“发布”仓库的概念——其中代码永远不会改变——以及“快照”仓库,您计划发布代码,但它可能会更改。如果您怀疑
bar
可能会因为您需要
foo
中的内容而更改,这很有帮助。