13

什么是更好的？

A：

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/...

乙：

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/...

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

4

6 回答 6

19

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

相反，按分支/标签分组对我来说没有意义，因为不同项目的分支没有任何共同点，只是它们都是分支。

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

另外：我们对每个客户都有单独的存储库，即客户的所有项目都在同一个存储库中。通过这种方式，您可以例如立即备份单个客户，或者将客户拥有的任何东西的源代码提供给他，而无需与 SVN 冲突。

于 2008-09-30T09:16:04.167 回答
17

SVN 书的存储库管理章节包括规划存储库组织的部分，概述了不同的策略及其含义，特别是存储库布局对分支和合并的影响。

于 2008-09-30T09:20:38.210 回答
8

我会建议一个选项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可以轻松管理在两个或多个应用程序项目之间共享的代码库项目。

于 2008-09-30T09:17:39.217 回答
1

我们使用设置 B。因为一次签出/标记多个项目更容易。在 svn 1.5 中，可以通过稀疏结帐，但不是一键式操作。如果某些项目在beetween 中有隐藏的依赖项，您想使用设置 B。

于 2008-09-30T09:20:03.843 回答
0

我们用

/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”存储库——项目完成后没人会关心的东西。

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

于 2008-09-30T10:03:36.937 回答
0

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

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

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

关于“多个 SVN 存储库与单个公司存储库”的问题，我也有回答。只要您在问题中解决存储库结构的这一方面，它可能会有所帮助。

于 2011-12-31T14:50:40.933 回答