我正在努力为以下问题找到可行的策略。
我们有几个依赖于我们框架的Web项目。一切都存储在我们的SVN中，并拥有自己的项目，包含所有必要的目录结构（主干，标签，分支）。在一个例子中 - 我们有项目webprj01和webprj02，我们有一个框架frm01。所有这些都有通常的SVN项目结构 - 主干，标签，分支。
webprj01和webprj01都依赖于frm01，在现实生活中，frm01作为webprj01和webprj02的子目录存在。要在SVN中实现这一点，可以设置svn：external属性，我们可以设置frm01指向webprj01和webprj02的trunk中的/ frm01 / trunk。
要进行现实生活中的编码，我们必须将所有三个项目都作为工作副本进行检出，然后对其自己的工作副本中的特定代码库进行更改。无法将更改从webprj01 / frm01发布到SVN。更改需要在frm01工作副本中完成，并通过SVN传输到webprj01 / frm01和webprj02 / frm01工作副本。
此解决方案在分支时存在依赖性问题。我从SVN / webprj01 / trunk创建了一个生产分支到/webprj01/branches/release-1.0.0。在处理第二个项目webprj02和frm01的两天内，我不再能够通过分支发行版1.0.0中的svn：externals进行稳定的结账。目录frm01已经指向frm01 / trunk的新更改。
描述的只是问题的简化版本。在我们的现实生活中，依赖关系有时会达到五个层次。我希望能够随时从SVN获得稳定的代码。换句话说。当我将webprj01分支/标记为release-1.0.0时。我想在创建后的一年内获得该特定标记的稳定代码。
很明显，使用svn：externals描述的策略不起作用。您对这种情况的体验是什么？没有必要使用一个结账。即使使用构建脚本或其他解决方案也会有所帮助。我正在寻找一个长期解决这个问题的方法，因为我们很容易出错，因此不会严重依赖人类行为。
答案 0 :(得分：6)
在Java世界中，我不会尝试仅使用版本控制系统来解决这个问题 - 我会使用像Maven +版本控制系统这样的依赖管理工具。
在我工作的地方，我们有一个看似很常见的设置：
任何“框架”项目都存在于它自己的目录结构（主干，标签，分支）中，就像您已经拥有的那样。这些也使用Maven进行管理，每当签入某些内容时，组件的新版本（在大多数情况下是JAR文件）将发布到我们的本地Maven存储库（驻留在Nexus服务器上）。
任何需要使用“框架”项目的项目都会依赖于特定版本的框架项目 - 然后Maven会在构建项目时自动从Nexus服务器中提取此版本。
这使我们能够单独发布每个项目和框架组件，但仍然可以跟踪它们之间的依赖关系。我们甚至可以拥有不同项目使用的多个版本的框架组件，而不会完全失去对依赖项的跟踪。
到目前为止，这对我们来说效果很好 - 我只能看到两个缺点：
设置需要一段时间，特别是如果您之前没有使用过Maven。
发布每个项目时会有一些开销，因为您还要释放每个依赖组件，以避免依赖于其他组件的“trunk”版本（即Maven术语中的“SNAPSHOT”版本）。
答案 1 :(得分：2)
Erik是对的，依赖经理会帮助你 - 可能想看看maven或者蚂蚁/常春藤。
使用svn：externals作为一个穷人的依赖管理器是一个黑客，需要很多纪律 - 它是一个PITA来弄清楚包含哪个版本的框架，然后一些小丑将设置外部参考项目到框架的主干，你将有一个非常艰难的时间来计算发布之间的delta。
过去我曾经有过js，css＆amp;许多项目的xsl通常被打包为.tgz文件，并通过简单的ant脚本发布到常春藤仓库，然后项目有ant build（和ivy.xml文件）来解析依赖关系然后打包整个东西。它工作但
前端网络人员在源代码管理方面苦苦挣扎，更不用说依赖管理了。很难让他们“得到它”足以将对公共模块的更改发布到本地存储库，然后构建一个依赖于它来进行更改的项目。
Erik提到的额外步骤，必须释放多个工件才能为生产做好准备。
肮脏的遗留设计意味着实际上在公共代码中的大多数变化，可部署的10个版本中的1个实际上在其代码中有变化......它通常包含在公共代码中。
认真 - svn：作为依赖管理的外部人员将会变得头疼。值得投资。虽然说这些家伙在依赖管理方面遇到了麻烦，但他们对你现在拥有的许多分支上的svn：externals的排序方式也不太可能。
如果我不得不再做那些事情 - 我会去找maven。