我正准备建立一个 SVN 存储库，想知道是否有人有一个很好的 repo 结构示例。我目前在想：
发展
.. 应用
.... 应用程序1
......后备箱
...... 分店
......标签
.. 数据库
.. 第三方
虽然这个结构可能可以容纳我们需要的一切，但我想让它更细化一些。有什么想法吗？
【问题讨论】：
标签： svn repository repository-design
我们从一个类似的模型开始，但发现它有点麻烦。主要问题是，如果你想在发布时分支你的代码库，你必须为每个组件创建分支。
相反，我们考虑了如下方案：
trunk
app1
app2
lib1
lib2
branches
rc-2.0
app1, app2, lib1, lib2...
some-devs-branch
app1, lib2
tags
release-1.0
app1, app2, lib1, lib2...
我喜欢完全为第 3 方的东西创建一个单独的存储库。除非您打算从red bean book 中实现完整的vendor-branching strategy，否则这将很有效。
【讨论】：
我们也一直在为此苦苦挣扎。
我们发现用不了多久，某些共享库就会成为多个应用程序的一部分，并且您希望所有内容都在同一个版本上。因此，我们决定将我们所做的一切都放在一个存储库中。我们已经以这种方式工作了 2 年多，并且发现它非常适合使用。
所有配置都有优点和缺点，但是通过拥有 1 个完整的存储库，您可以（几乎）确保所有文件都处于正确的版本。如果您使用多个主干，则可以使用虚拟文件夹或链接（我忘记了这个术语）来使其相互链接，但是要回到原来的位置非常困难。
请记住每个配置都有优点和缺点，但对于一家规模不大的公司，我建议将所有内容放在一个带有一个父文件夹的单个存储库中。
【讨论】：
我目前的方法是在一个存储库下打破逻辑应用程序边界上的系统。
例如，假设一个服务也有一个测试套件和一个数据库
/project1/application1/
trunk/
Src
Test
Database
tags/
branches/
application2/
trunk/
Src
Test
tags/
branches/
这允许我们将多个应用程序与一个项目相关联，但处理每个“逻辑”应用程序边界的发布控制。考虑你的发布控制需要在哪里/什么，并将它们设置为分支/标签/主干结构的位置。
我不喜欢整个存储库根目录下的单个 trunk/branches/tags 文件夹，因为我不想签出整个主干，也不想将部分分支签出弄乱结果。 （您可能不同意，您的里程可能会有所不同等）
【讨论】：
SVN 提供标签以在特定时间获取源树的“时间快照”（您可以将其用于发布等）。
但如果您打算让您的存储库“更细化”，也许您应该考虑设置多个存储库。
当然，在“主干”文件夹中，如果不使用源代码控制，您应该设置任何正常的目录层次结构。
【讨论】：
我们总是为每个单独的“解决方案”创建一个单独的 SVN 存储库。这个存储库只有一个简单的主干、分支和标签结构。
任何依赖的框架（我们控制源代码的地方）都有自己独立的存储库。然后，我们通常只将二进制文件（特定版本）包含到任何使用它们的项目中。
【讨论】：
对所有内容都拥有一个存储库意味着您很有可能很快就拥有一个庞大的存储库。这意味着事情可能会变得缓慢并且也有点难以跟踪。显然，这取决于您的确切用例，但我个人会选择每个项目的存储库并在需要时使用 svn:externals。
实际上，如果可能的话，我会选择分布式 VCS 而不是 SVN，但每个人都有自己的...
【讨论】：