0

我们有几个 Zend_Framework 应用程序，我们希望将它们保存在单独的 subversion 存储库中。但是，这些应用程序共享相同的数据库抽象层和几个相同的通用组件。

我们想以某种方式分享应用程序之间的共同点。我们目前的想法看起来像

svn://foo/itg-common/trunk
svn://foo/itg-common/branches/foo
svn://foo/itg-common/branches/production

svn://foo/itg-app/trunk
svn://foo/itg-app/branches/foo
svn://foo/itg-app/branches/production

现在，我们希望 itg-app 存储库具有对 itg-common 存储库的外部引用。问题是我们希望例如itg-app/trunk/common被链接到itg-common/trunk，itg-app/branches/foo/common被链接到itg-common/branches/foo等等。也就是说，一般模式是itg-app/$BRANCH/common -> itg-common/$BRANCH。

现在，原则上我们可以创建这些外部，但是每当我们尝试合并时就会出现问题。$/trunk例如，从to合并$/branches/production将覆盖要指向的svn:externals属性。$/branches/production/commonitg-common/trunk

这有意义吗？如果是这样，有没有办法解决这个问题？如果没有，为什么不呢？我们应该怎么做呢？

4

2 回答 2

3

这有意义吗？如果是这样，有没有办法解决这个问题？如果没有，为什么不呢？我们应该怎么做呢？

正如prodigitalson已经说过的那样，SVN 中的外部基本上被认为是一个完全不同的软件，有自己的发布周期、分支、标签等。根据这个模型，你根本不应该将外部固定到某个主干中，但有它们都固定在标签或修订版上。这是使用来自外部源代码的非常受限的模型，但这正是 SVN 支持的。偏离这一点，你就靠自己了。（有关我个人的战争故事，请参见下文。）

如果我是您，我会重新考虑的另一件事是指不同的存储库。相对于当前项目或存储库根目录引用外部的 IME 比使用绝对路径要好得多。只需考虑您可能将协议从更改为的可能性svn:，例如，https:. （我已经看到这种情况发生在一家公司中，尽管严重依赖脚本来更改所有外部，但这种转变是一个混乱，每个参与其中的人都在做噩梦。）外部的相对路径更健壮，但它们只在内部可用单个存储库。

我工作的公司刚刚遇到了类似的问题。我们有很多在不同产品之间共享的代码。这是通过外部完成的，而那些外部引用的项目本身也有外部。在某些地方，我们只需要三层递归外部，而且我们已经知道未来还会有更多。所有这些代码都在不断地工作，我们希望让外部引用他们所引用的项目的主干，因为自动测试会消除这一点，并且管理所有这些递归外部的发布将需要我们根本无法承受的努力。

但是在这种情况下分支一个项目是一个真正的痛苦，呃，脖子，因为固定项目的外部是不够的，当它们本身引用未固定的外部时。每当您需要将 project 分支foo到foo'（通过外部引用 project X，而后者又通过外部引用 project XX）时，您将需要一个foo'分支，XX该分支是 的分支中的外部，该foo'分支X是 的外部foo'本身。想象一下，其中有六个外部foo组件，其中一半有自己的外部组件，一些递归三层甚至更多层，您会发现项目XXX中到处都是为它甚至不应该知道的项目创建的分支。

我们的解决方案是递归地要么A)用它们所引用的分支替换所有外部，要么B)设置一个外部分支，该分支X由foo/branches/externals/foo'/X(<project>/branches/foo'自身foo/branches/externals/foo'/X引用foo/branches/externals/foo'/XX) 引用。但是，在创建时进行设置foo'非常复杂，并且提供了足够多的犯愚蠢错误的机会，因此我们使用脚本来递归下降项目及其外部并完成所有这些。

于 2011-10-27T09:16:04.307 回答
1

您应该只在应用程序中的单个存储库外部。我假设这将是您的公共回购中的“生产”分支。基本上，您将外部视为具有自己的开发生命周期的独立项目。

于 2011-10-27T03:04:55.393 回答