svn - 需要存储库布局引用

Question

我期待一场关于 Subversion 存储库的战斗:目前我们有一个 web 应用程序，它被 checkin 为 3 个主要项目和 2 个报告项目(当我 6 个月前开始时)，现在最多有 7 个项目，并且是预期的进一步发展。

对我来说很明显这是不对，如果您想合理使用版本控制系统，编译后的可执行文件不能跨越版本控制边界。不可能为单个功能进行一次 checkin ，这对我来说似乎很重要。

但当我试图解释这一点时，我觉得我在挥手。对于 Subversion 或一般情况，是否有人有任何引用资料阐明了这一原则并在其背后有一定的权威？我已经进行了一些搜索，只是没有找到我需要的东西。

Answer 1

在 Subversion 中有很多选项可以用来构建你的版本库。查看discussion of repository layout在文档中。

我通常会遵守这些规则:

• 是不同的项目、没有重叠、不是相同的用户或组吗？==> 你可以使用不同的存储库(但不是强制的。
• 是否存在将相互独立地跟踪和构建的独立部分？ ==> 使用所谓的“多项目布局”(见下文)。
• 您是否开发了一个应用程序，并在不同的团队中工作，使用所谓的“单一项目布局”。

区别如下:

• 单一项目布局:

   Repo MyProject:
   trunk/
     java/
       src/
     ruby/
     doc/
     ...
   tags/
     rel1.0/
       java (references the copy of java of revision xxx)
       ruby (references the copy of ruby of revision xxx)
       ...
     rel1.1/
       ...
   branches/
     feature_x/
       java (references the copy of java of revision yyy)
       ...
  

• 多项目布局:

   Repo MyProjectBundle:
   proj1/
     trunk/
       java/
         src/
     tags/
       rel1.0/
         java (references the copy of java of revision xxx)
         ...
       rel1.1/
         ...
     branches/
       feature_x/
         ...
   proj2/
     trunk/
     tags/
     branches/
   ...  
  

所以主要区别如下:

• 在多项目布局中，很难对所有项目进行标记和分支，通常只标记一个项目。
• 它是一个单一的项目布局，你可以随意分支和标记，并且通常是整个主干。然后，您可以更改您想要更改的内容，在一次修订中提交所有内容，然后一步将其合并回来。

作为引用，我只有引用的SVN红皮书，当然还有stackoverflow中的众多答案之一:Subversion Repository Layout