5

我们理解默认和通常推荐的 svn 存储库组织，如果有多个项目，是这样的：

root/projectA/(trunk, branches, tags)
root/projectB/(trunk, branches, tags)
...

我们的项目有很多相互依赖，这需要在它们之间广泛使用svn:externals，考虑到我们不做 dll 引用内部项目，我们更愿意查看它们的源代码而不是使用二进制文件。

过多地使用外部，在分支存储库、同步更改时，可能会变得复杂且容易出错，因此团队根本不信任这个解决方案。

因此，一位团队成员提出了一些我们都认为这可能是更好的解决方案：将所有项目放在同一个主干中。

起初，我们认识到这种方法存在一些问题，但总的来说，我们同意这些问题是基于我们很可能从未经历过的假设情况。

您是否看到我们在使用此解决方案时可能遇到的一些严重问题？

4

4 回答 4

4

我们在公司这样做，并取得了很大的成功。

我们有 3 个顶级目录：

  • 标签
  • 分支机构
  • 树干

然后我们将每个项目作为这些项目的子目录。

尽管如此，我们仍然在项目级别进行分支，并且仍然使用 svn:externals。但是如果我们有一个较小的源树，我们会在主干级别分支而不使用 svn:extenrals。

能够将所有项目的主干放在同一个地方真是太好了。你可以备份它，你可以检查它，你可以把所有最新的东西放在一起。您不会丢失所有分支的单个位置，也不会丢失所有标签的单个位置，因为它们都位于 /branches/projectX 和 /tags/projectX 的子目录中

svn:externals 的问题：

如果您的项目不是非常庞大，那么您可以每次只分支整个主干，并避免 svn:externals 的所有问题。

svn:externals 的问题在于，当你创建一个分支时，它不会自动为你的每个 svn:externals 创建一个分支。这是一个问题，因为随着时间的推移，随着主干的更新，所有旧分支都将无法编译。另一个问题是，如果您在任何分支中对 svn:external 进行修复，所有其他分支都会中断。

svn externals 的另一个问题是，当您在根级别执行 svn:log 时，您看不到 svn externals 的任何更改。

希望有一天 svn externals 能够解决上述问题，但在那一天之前，分支和 svn:externals 绝对是一场噩梦。

于 2009-04-28T19:39:49.943 回答
1

to "putting all projects into same trunk":

From my experience this is no good idea - because each project has it's own history and changes and often projects are/will be maintained by different developers. This can lead to conflicts - even if you state out, that currently the projects interfere heavily.

So why don't you use common tags (with milestones as names to) for all of your projects to ensure a same code base and a build script, which can check out the projects (trunks) automagically? It's more work, but like usual in OOP (capsulation) I would prefer to split the projects into separate SVN directories, too.

But: Collecting a bunch of small libs and apps into a common directory under the same trunk is no problem (see "apps" and "tools" in my example below) - so maybe "small projects" can stay in the shared/big trunk.

Here as example my directory structure of SVN:

/projects/
/projects/CustomerA/
/projects/CustomerA/ProjectX/
/projects/CustomerA/ProjectX/trunk/
/projects/CustomerA/ProjectX/tags/
/projects/CustomerA/ProjectX/branches/
/thirdparty/
/thirdparty/ExtLibY/
/thirdparty/ExtLibZ/
/tools/
/tools/trunk/
/tools/tags/
/tools/branches/
/apps/
/apps/trunk/
/apps/tags/
/apps/branches/

So all of the external stuff is stored in /thirdparty/ and all internals (projects, tools, apps) have the subdirs:

/trunk/
/tags/    
/branches/

...like advised in the Subversion book and the previous post.

Even if that looks a little bit much efforts at first sight - it is really worth it, especially when your code base grows.

ciao, Chris

于 2009-04-28T20:45:41.610 回答
1

您是否看到我们在使用此解决方案时可能遇到的一些严重问题？

  • 只要您可以将所有内容放在一个存储库中，您的解决方案就可以工作。

    这意味着在可预见的未来，整个存储库必须适合单个磁盘（或存储池）。类似的考虑适用于其他服务器资源，例如网络和磁盘 I/O 带宽。

    稍后拆分存储库将需要对整个设置进行大修，并且当您需要重建或分支旧版本时可能会令人头疼。

  • 仅当您不需要限制每个用户的读/写权限时，您的解决方案才有效

    如果您需要授予 projectA 的读/写权限，您实际上必须授予 /trunk/projectA、/branch1/projectA 和 /branch2/projectA 等的权限。

    然后分支成为一个需要大量权限调整的重量级过程。告别特色分支。

于 2009-04-28T23:52:46.730 回答
1

你所做的就是我在我公司设置的，在 svnbook 主题Strategies for Repository Deployment中也被称为“非常常见的布局” 。

它没有错。

于 2009-04-28T19:53:28.897 回答