什么是更好的？

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

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

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

解决方案

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

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

但最终，人们会同时使用两种方式。做自己喜欢的事，但是当我们决定时，请尝试坚持下去:)

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

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

我们使用设置B。Beause可以更轻松地一次性签出/标记多个项目。在svn 1.5中，可以通过稀疏签出，但不能一键式操作。
如果某些项目之间具有隐藏的依赖关系，则要使用设置B。

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

我们用

/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"存储库-项目完成后没人会在意的。

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