如何更新 Subversion 外部组件
我们有几个 Subversion 存储库：一个用于公共代码，一个用于每个顶级项目。顶级项目有一个 svn:external 链接到公共存储库的主干。
在构建项目的版本之前，我们创建顶级项目的分支，并在公共存储库中创建并行分支。
我们如何自动确保分支顶级项目中的 svn:external 属性指向公共目录中的并行分支 - 目前它将指向公共存储库中的“trunk”。我们目前必须在分支项目中手动编辑它。
谢谢
We have several subversion repositories: one for common code and one for each top level project. The top level projects have a svn:external link to the trunk of the common repository.
Before we build a release of a project we create a branch of the top level project and also create a parallel branch in the common repository.
How can we automatically ensure the svn:external property in the branched top level project points to the parallel branch in the common directory - currently it will be pointing to "trunk" in the common respository. We are currently having to manually edit this in the branched project.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我理解你的意思，你想确保 foo 和 bar 共享同一个分支。
foo是您的主项目，并且其上有一个svn:externals指向bar。当您分支foo时，您需要确保bar使用相同的分支。确保这一点的唯一方法是在存储库的根目录而不是项目的根目录中使用tags和branches目录创建存储库（就像大多数网站一样） ）。然后，您可以使用相对外部引用从包含
svn:external的foo目录指向bar。另外，如果您使用相同的标签标记 foo 和 bar，则 foo 和 bar 将保持它们的关系：如果您的分支位于存储库的根目录，则
common目录将指向同一分支对于foo来说，就像它在bar上一样。snv:externals的一个大问题是，如果您不小心，您就会指向所链接目录的不断变化的版本。假设有人在我的
foo项目中这样做了。我进行发布并将foo复制到标签。但是，当有人更新bar/trunk时，我标记的common目录将会被修改。这使得重建foo几乎不可能。当我使用
svn:externals时，我总是确保链接到bar的标记版本或特定修订版，并且如果我链接到特定版本如果有人决定删除我链接到svn:externals属性的目录，我还会将我的 URL 与该修订版挂钩。Subversion 中没有任何内容会自动更新您的
svn:externals属性，但您可以使用我发现
svn:externals搜索目录树上的所有 svn:externals > 通常最终会带来比其价值更大的痛苦。相反，我只是将
bar的构建对象或源代码的压缩副本存储在我的发布存储库中，并且作为构建过程的一部分，我将对象或压缩源代码从我的发布存储库中复制出来。即使我没有做 Maven 项目，甚至没有在基于 Java 的项目中工作，我也使用 Nexus 或 Artifactory 等 Maven 站点存储库作为我的发布存储库。本地 Maven 存储库提供了上传和下载依赖包所需的所有工具，此外 Maven 还具有发布存储库（其中代码永远不会更改）和快照的概念。 em> 存储库，您计划在其中发布代码，但它可能会发生变化。如果您怀疑
bar可能因为foo中需要的内容而发生变化，这会很有帮助。If I understand you, you want to make sure that
fooandbarshare the same branch.foois your master project and has ansvn:externalson it somewhere pointing tobar. When you branchfoo, you want to make surebaris using the same branch. The only way to ensure that is to create your repository with thetagsandbranchesdirectories at the root of your repository instead of at the root of the project (like most sites do).Then you can use relative external references to point from the
foodirectory that contains thesvn:externalback tobar. Also, if you tag foo and bar with the same tag, foo and bar will maintain their relationship:If your branches were at the root of your repository, then the
commondirectory will be pointing to the same branch forfooas it is onbar.The big problem with
snv:externalsis that if you're not careful, you're pointing to an ever changing version of the directory you're linking to. Let's say someone did this:in my
fooproject. I do a release and copyfooto a tag. However, thecommondirectory that I've tagged will be modified when someone updatesbar/trunk. This makes it almost impossible to rebuildfoo.When I use
svn:externals, I always make sure I'm linking to either a tagged version ofbar, or a specific revision, and if I am linking to a specific revision, I also peg my URL to that revision in case someone decides to delete the directory I'm linking to mysvn:externalsproperty.There's nothing in Subversion that will automatically update your
svn:externalsproperties, but you can search for all svn:externals on a directory tree by usingI've found that
svn:externalsusually ends up being a bigger pain than it's worth.Instead, I simply store the built object of
baror a zipped up copy of the source in my release repository, and as part of my build procedure, I copy the object or zipped source out of my release repository.I use Maven site repositories like Nexus or Artifactory as my release repository even if I am not doing a Maven project or even working in a Java based project. The local Maven repository provides all the tools you need to upload and download your dependent packages, plus Maven has the concept of release repository -- where the code never changes -- and a snapshot repository where you're planning on releasing the code, but it could change. This is helpful if you suspect that
barcould change because of stuff you need infoo.