Question

什么更好？

答

server:1080/repo/projectA/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...
server:1080/repo/projectB/trunk/...
                          branches/branch1
                          branches/branch2
                          branches/branch3
                          tags/tag1/...
                          tags/tag2/...

B：

server:1080/repo/trunk/projectA/...
                 branches/projectA/branch1
                 branches/projectA/branch2
                 branches/projectA/branch3
                 tags/projectA/tag1/...
                 tags/projectA/tag2/...
server:1080/repo/trunk/projectB/trunk/...
                 branches/projectB/branch1
                 branches/projectB/branch2
                 branches/projectB/branch3
                 tags/projectB/tag1/...
                 tags/projectB/tag2/...

您使用什么存储库结构？为什么？

Answer 1

我们使用A，因为另一个对我们没有意义。请注意，关于SVN的“项目”不一定是单个项目，但可能是几个属于一起的项目（即，您将在Visual Studio中放入解决方案）。这样，您就可以将任何相关的组合在一起。所有分支，标签和特定项目的主干。对我来说很有意义。

通过分支/标记进行分组对我没有意义，因为不同项目的分支没有任何共同之处，只是它们都是分支。

但最终，人们使用两种方式。做你喜欢的，但是当你决定的时候，试着坚持下去：）

作为补充：我们为每个客户提供单独的存储库，即客户的所有项目都在同一个存储库中。这样你就可以这样立即备份单个客户，或者在不与SVN抗争的情况下提供客户拥有的任何内容的源代码。

Answer 2

Repository Administration的SVN book章节包含Planning Your Repository Organization部分，其中概述了不同的策略及其含义，尤其是the implications of the repository layout on branching and merging。

Answer 3

我建议选择C：

server:1080/projectA/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...
server:1080/projectB/trunk/...
                     branches/branch1
                     branches/branch2
                     branches/branch3
                     tags/tag1/...
                     tags/tag2/...

我更喜欢将单独的项目保存在单独的存储库中。使用svn:externals可以轻松管理在两个或多个应用程序项目之间共享的代码库项目。

Answer 4

我们使用设置B.因为一次检查/标记多个项目更容易。在svn 1.5中，可以通过稀疏结账，但不是一键操作。如果某些项目之间存在隐藏的依赖项，则您希望使用设置B.

Answer 5

我们使用

/repos/projectA/component1/trunk - branches - tags
/repos/projectA/component2/trunk - branches - tags
/repos/projectB/component3/trunk - branches - tags
/repos/projectB/component4/trunk - branches - tags

我开始后悔。它应该更平坦。这会更好。

/repos/projectA/trunk - branches - tags
/repos/projectB/trunk - branches - tags
/repos/component1/trunk - branches - tags
/repos/component2/trunk - branches - tags
/repos/component3/trunk - branches - tags
/repos/component4/trunk - branches - tags

为什么呢？产品（组件，成品软件）永远存在。项目来去匆匆。去年只有一个项目团队正在创建产品QUUX。明年，该团队分散，一两个人维持QUUX。明年，将有两个大的QUUX扩展项目。

鉴于时间表，QUUX应该出现在三个项目存储库中吗？不，QUUX独立于任何特定项目。确实，项目确实有工作产品（文档，积压等），这些工作产品是完成工作的一部分，但不是工作的实际目标。因此，该材料的“projectX”存储库 - 在项目完成后没有人会关心的东西。

我参与了一个有三个团队的产品。协调工作的大问题是因为每个项目都独立管理它的存储库。有团队间发布和团队间协调。在那天结束时，它应该是一个软件。但是，正如您所猜测的那样，它是三个具有奇怪重叠和冗余的软件。

Answer 6

我个人使用以下存储库结构：

/project
    /trunk
    /tags
        /builds
            /PA
            /A
            /B
        /releases
            /AR
            /BR
            /RC
            /ST
    /branches
        /experimental
        /maintenance
            /versions
            /platforms
        /releases

还有一个diagram说明了如何使用这些目录。我还使用了特定的版本编号方法。它在存储库结构中起着重要作用。最近，我开发了专门用于软件配置管理的培训，其中我描述了版本编号方法以及为什么这个存储库结构最好。这是presentation slides。

answer上还有关于'多个SVN存储库与单个公司存储库'的{{3}}。只要您在问题中解决存储库结构的这一方面，它可能会有所帮助。

你如何构建你的SVN存储库？

6 个答案: