SVN存储库结构 - 为什么这更好？

Question

我被告知大多数开发商店都有以下结构或者至少接近这个结构:

• 主存储库
  • 下面的项目文件夹
  • 每个Project文件夹都有一个trunk,branches和tags文件夹

所以:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
        ...

那为什么这更好或更好？如果你以另一种方式做到,会发生什么或者你有什么心痛？

Answer 1

大多数人这样做是因为它是Subversion书籍推荐的.

以下是CollabNet Subversion项目主管的一个很好的解释:

http://blogs.collab.net/subversion/2007/04/subversion_repo/

Answer 2

这种组织存储库的方式:

ReponsitoryMain
    Project1
        branches
        trunk
        tags
    Project2
    ...

当您的项目没有彼此连接/相互依赖时,这是最好的.另一种方法可以更轻松地对整个项目套件进行版本控制.因此,如果您经常将Project1和Project2一起发布/打包,最好让它们共享同一个分支.

另一方面,如果您的项目非常分离并且有完全不同的团队在处理它们,那么您不需要在大多数时间一起检查它们,因此您可以使用上述方法.

Answer 3

存储库结构取决于您的需求.如果您的项目完全分离(它们之间没有依赖关系),那么这个"简单"的存储库结构就可以了.如果你的项目中有依赖项(例如一些全局"工具库",共享代码),你应该使用不同的结构,如:

trunk
   prj_a
   prj_b
tags
   <YOUR_TAGNAME>
       prj_a
       prj_b
branches
   <YOUR_BRANCHNAME>
     prj_a
     prj_b

或其他任何对你的过程更有意义的东西.

在具有本地主干/标签/分支的简单结构中,如果您之间存在依赖关系,则无法(至少以干净的方式)标记多个项目.

此外,经常提出的"多存储库"方法不会填补这个空白,因为在多个存储库中您注定了多个修订或标记.

主要问题是SVN 不支持共享资源和标记/分支它们.

如果您考虑一下您的存储库结构,您应该问自己在哪个过程中要共享您的代码库.

Answer 4

好吧,我会更加快乐,并坚定地站在每个项目的主干,标签和分支的一边.

主要的选择是拥有一个主干,标签和分支,下面是所有项目.然而,这导致了许多问题,其中一个问题很重要,我将在这里详述:

它主要为不可触及的图书馆铺平了道路,每个人都害怕接触特定的图书馆,因为任何改变都可能会在一些随机项目中打破一些微妙的东西.造成这种情况的原因是,由于项目之间没有分离,任何人都可以有效地更改项目中的代码,而无需检测或控制它.

发生的事情是,有一天你检查了你的项目并建立了它,第二天你检查它并且它失败了,但你没有对你的项目做任何改变.发生的事情是有人改变了你所依赖的图书馆.在具有许多依赖关系的大型结构中,开发人员针对每个项目测试库更改是不现实的,特别是如果他们必须进行重大更改.您在项目中需要的是对特定版本库的引用.这样,只有在更改对最新版本的引用时,库才会更新.

这种引用有3个效果:1您的项目与库的随机中间开发更改隔离开来.2您在项目中得到一个修订版,告诉您"我现在正在使用此版本的库".3.您可以控制何时对项目进行更改以解决库中的任何重大更改.

如果这还不够,还有其他问题我可以通过.

Answer 5

我们为每个项目保留一个单独的存储库.

虽然这不允许您将版本历史文件从一个项目复制并保存到另一个项目,但它允许您在项目结束时归档整个存储库.