13

我负责几个（相当小的）程序，它们通过不同的库共享大量代码。我想知道最好的存储库布局是开发不同的程序（和库），并使库在所有程序中保持同步。

为了争论，假设有两个程序有两个库：

  • 程序1
    • 图书馆1
    • 图书馆2
  • 程序2
    • 图书馆1
    • 图书馆2

自然地，库的错误修复和增强应该（最终）合并到所有程序中。由于在处理不同程序时正在处理这些库，因此使用外部定义似乎是不可能的。

所以我想把我的图书馆除了一个地方当作供应商分支，但我不确定最好的布局是什么。

我在想一些事情：

  • 图书馆
    • 图书馆1（祖先）
    • 图书馆2（祖先）
  • 程序1
    • 程序1代码
    • Library1（供应商分支）
    • Library2（供应商分支）
  • ...

然后说在开发 Program1 时对 Library2 进行了一些更改，我将它们合并回存储库的库部分，并在需要时将它们从那里合并到所有其他程序。

合并到其他程序并不总是立即发生，在 Program2 上工作的人可能会接近发布，而是先完成发布，创建一个标签，然后才更新所有库。

我有点担心这会在一段时间后导致许多合并和一些维护头痛，但我真的没有看到更好的解决方案。

再说一次，这对我来说似乎是一个相当常见的用例，所以我想我只是问问 stackoverflow 社区，实现这一目标的最佳存储库布局是什么？

4

2 回答 2

9

好吧，我想我不同意外部因素是不可能的。我过去也遇到过类似的问题。我使用 svn 属性外部解决了它。

创建您的库存储库：

svnadmin create /path/library1
svnadmin create /path/library2
...

创建客户端存储库：

svnadmin create /path/program1
svnadmin create /path/program2
...

现在将库声明为程序存储库中的外部库：

cd /path/program1
svn propset svn:externals "library1 svnpath://wherever/library1/trunk/" .
svn propset svn:externals "library2 svnpath://wherever2/library2/trunk/" .

现在，您可以对程序 1 和 2 进行更改，并且在这些项目的根目录进行提交不会影响库......但是，如果您需要对库进行更改，您可以。然后，当且仅当您对库存储库具有写入权限时，您也可以提交这些更改 - 但只能从库的子目录中提交。

即这不会对库做出承诺......

... make a change in /path/program1/library1 ... 
cd /path/program1
svn commit -m "some change"

这提交了在上面的库中所做的更改：

cd /path/program1/library1
svn commit -m "change to library code"
于 2008-10-13T19:48:52.717 回答
1

为什么库的源代码必须存在于程序树中。分别编译您的库并将它们链接到您的程序中。

于 2008-10-13T19:44:00.447 回答