小公司的SVN存储库结构？

Question

我目前设置的存储库设计是标准方法：

Application1
    trunk
        DatabaseScripts
            CreateScripts
                CreateTable1.SQL
                CreateTable2.SQL
            StoredProcs
                StoredProc1.SQL
                StoredProc2.SQL
        Solutions
            MainSolution.sln
            Project1
                Project1.csproj
                Project1Class1.cs
            Project2
                Project2.csproj
                Project2Class1.cs
    tags
        1.0.0
        1.0.1
    branches
        developer1
        developer2

并为每个应用程序重复。这在过去对我很有帮助 在处理非常大的代码库时。

不过这家公司很小，目前有 大约 8 个应用程序，每个应用程序都相当小。只有一个 很少有开发人员，所以我们很少需要分支/标记。

我对当前设置的唯一问题是，如果 有人想查看我们所有应用程序的源代码， 唯一的方法是检查每个单独的应用程序 主干，一次一个，或者检查所有内容然后删除 分支和标签。

所以我在考虑以下结构：

trunk
    Application1
        DatabaseScripts
            CreateScripts
            StoredProcs
        Solutions
            MainSolution.sln
    Application2
        DatabaseScripts
            CreateScripts
            StoredProcs
        Solutions
            MainSolution.sln
tags
    Application1
        1.0.0
        1.0.1
    Application2
branches
    Application1
        developer1
        developer2
    Application2

我注意到 SVN 书中提到了这种模式，他们称之为“项目作为分支兄弟姐妹”： http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

除了书中所述之外，谁能指出这个设计中的任何不足之处？

Answer 1

我经常问的问题：你们是如何发布的？

例如：如果每个应用程序都是一个独立的版本，那么每个应用程序都会有自己的分支和标记。因此，每个应用程序都应该有自己的 tags 目录和自己的 branches 目录。这意味着每个应用程序也有它自己的trunk。因此：

app1
    trunk
    branches
    tags
app2
    trunk
    branches
    tags
app3
    trunk
    branches
    tags

但是，如果这些应用程序作为单个套件发布（想想 Microsoft Office），它们将共享标签，并且可能还会共享分支。而且，他们将共享一个后备箱。因此：

trunk
    app1
    app2
    app3
branches
    app1
    app2
    app3
tags
    app1
    app2
    app3

现在，问题是关于数据库，以及在什么目录结构下...

数据库是发布管理中最棘手的部分，因为它们涉及的不仅仅是一些代码。应用程序的每个版本都需要脚本，这些脚本不仅可以创建数据库，还可以从任何版本更新数据库。而且，有时我们有需要更改数据库的中间版本。

我发现最简单的解决方案是将这些类型的脚本的需求交给开发人员。我们要求应用程序在启动时自行更新数据库。我们在数据库中使用了版本号。突然之间，数据库更改变得更加罕见且更易于处理。

问题是谁负责更新数据库和数据库脚本。我更喜欢将脚本放在应用程序的目录下，因为它会像应用程序一样进行版本控制。但是，如果数据库几乎是一个单独的项目（甚至可能是一个单独的存储库），我已经在它自己的目录下看到它。有时我会同时看到：数据库开发的某些部分在其自己的目录下，有些在应用程序下：

database
    trunk
    branches
    tags
app1
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code
app2
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code
app3
    trunk
       database
       code
    branches
       database
       code
    tags
       database
       code

抱歉，我无法给您一个明确的答案，但您安排存储库结构的方式取决于发布的方式。

顺便说一句，我总是有一个分支和标签目录，尽管在非常小的商店里，分支目录有时是空的。如果你需要它就在那里。如果你不这样做，你就不会分支。

在非常小的商店中，有时会在版本发布后创建分支，然后进行热修复。没关系，您只需从发布标签分支。没什么大不了的。

Answer 2

只有少数开发人员，所以我们很少需要分支/标记

错误的假设，我不得不说：我独自工作，但有分支以便拥有可管理的代码

所有应用程序的一个 repo 有 一个 两个三个缺点：

• 常见的修订历史记录（修订数量不再是单个应用活动的标志）
• 您可以合并（尝试合并）来自不同项目的不相关 URL
• *-hooks 每个 repo 都是全局的，因此 - 您必须在其中包含更复杂的逻辑，以便在一个 常见的情况下区分 不同应用程序 的操作回购