logo标签列表

你如何构建你的SVN代码库？

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

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

你使用什么样的代码库结构，为什么选择这种结构？
一个简单的教程，教你如何构建你的SVN仓库。基本上，使用多项目结构总是更好的。http://www.deaddevssociety.com/2010/08/create-subversion-repository.html - user407665
6个回答
19

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

按照分支/标签分组对我来说没有意义，因为不同项目的分支除了都是分支外没有任何共同点。

但最终，人们会同时使用两种方法。做你喜欢的事情，但当你决定了，尽量坚持它：）

作为补充：我们每个客户都有单独的存储库，即一个客户的所有项目都在同一个存储库中。这样，您可以一次备份单个客户，或将客户拥有的任何东西的源代码交给他而不必与SVN纠缠。

17
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可以轻松管理被两个或多个应用程序项目共享的代码库项目。

1

我们使用设置B，因为可以一次检查/标记多个项目，更加方便。在svn 1.5中，通过稀疏检出是可能的，但不是一键操作。如果某些项目之间存在隐藏的依赖关系，则应使用设置B。

0

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

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

还有一个图示说明这些目录的使用方式。此外，我采用了特定的版本编号方法，在仓库结构中起着重要作用。最近，我开发了一项专门针对软件配置管理的培训，其中我阐述了版本编号方法以及为什么这种仓库结构是最好的。这里是演示文稿幻灯片。

此外，我在问题上回答了关于“多个SVN仓库与单个公司仓库”的问题。只要你在问题中涉及到仓库结构方面的内容，它可能会有所帮助。这里是我的回答链接。

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”存储库用于存储这些材料 - 在项目完成后，没有人会关心这些东西。

我曾经参与过一个有三个团队的产品开发。由于每个项目都独立管理其存储库，因此协调工作存在很大问题。存在跨团队发布和跨团队协调。最终，它应该是一个软件，但是，正如您所猜测的那样，它是三个具有奇怪重叠和冗余的软件。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接