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个应用程序，每个都相当小。只有一个很少有开发人员这么少，我们需要分支/标记。

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

所以我在考虑以下结构：

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书中提到了这种模式，他们称之为＃34; project-as-branch-siblings＆＃34;： http://svnbook.red-bean.com/nightly/en/svn.reposadmin.planning.html#svn.reposadmin.projects.chooselayout

除了书中所述之外，有人能指出这个设计中的任何缺陷吗？

Answer 1

我一直在问的问题：你如何做你的发布？

例如：如果每个应用程序都是独立版本，那么每个应用程序都将拥有自己的分支和标记。因此，每个应用程序都应该拥有自己的标记目录和它自己的分支目录。这意味着每个应用程序也有自己的 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

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

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

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

Answer 2

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

错误的假设，我不得不说：我单独工作，但拥有分支机构才能拥有可管理的代码

所有应用程序的一个回购都有一个两个三个缺点：

通用修订历史记录（修订版数不再是单个应用程序活动的标志）
您可以合并（尝试合并）来自不同项目的无关网址
* - 挂钩是全球每个回购，因此 - 您必须在其中包含更复杂的逻辑，以便在一个公共区域中区分不同应用的操作回购

一个小公司的SVN存储库结构？

2 个答案: