小型公司的SVN存储库结构？

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

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书中提到了这种模式，他们称之为“作为分支兄弟的项目”：

---

除了书中提到的那些，还有谁能指出这个设计中的不足吗？

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

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

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

然而，如果这些应用程序作为一个单独的套件发布（比如微软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

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

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

---

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

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

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

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

然而，如果这些应用程序作为一个单独的套件发布（比如微软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

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

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

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

开发人员很少，我们很少需要分支/标记

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

所有应用程序的一次回购有一、二、三个缺点：

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

开发人员很少，我们很少需要分支/标记

坏事