在为 subversion 创建项目时，每个单独的项目是否应该包含自己的主干、分支和标签目录？例如。
我的项目 1
- 分支机构
- 标签
- 后备箱
我的项目 2
- 分支机构
- 标签
- 后备箱
等等...
或者每个项目本身都应该放在一个包罗万象的结构中吗？例如。
分支机构
标签
后备箱
- 我的项目 1
- 我的项目 2
等等……
【问题讨论】：
标签： svn version-control
如果需要，选项 1 会更容易拆分为不同形式的源代码管理，因此是我更喜欢的。
在我看来，在第一个选项中管理项目范围的权限会更容易。
【讨论】：
这两种方法都很常见，尽管第一种方法更常见。
更常见的是为单独的项目设置单独的存储库 - 人们无法忍受在“他们的”存储库中有“不相关”的东西的想法。
【讨论】：
我个人选择选项 1。这是因为选项 2 存在以下相当微妙的问题：
使用选项 2，使您的工作副本与存储库结构相匹配是很常见的。这意味着您可以有效地签出整个副本（或其中的一部分，但具有相同的总体结构）。
当涉及到依赖项时，这是一个问题，比如 projectA 和 projectB 引用 libraryC，在库中所做的更改与应用于 2 个项目的更改之间没有控制。一旦提交到 libraryC 的主干，它就会被所有使用它的项目拾取。这样做的最终结果是您害怕更改 libraryC，因为它可能会破坏其中一个项目。
使用选项 1，您可以使用外部将特定版本的 libraryC 引入 projectA 和 projectB。事实上，如果需要，A 和 B 可以使用不同的版本。
这意味着您可以随意更改 libraryC，然后控制更改何时应用于项目 - 根据需要测试和更改代码，并知道您正在升级到最新版本的库。如果升级存在根本问题，您可以继续使用旧版本，直到库的问题得到解决。
另一种看待这个问题的方式是，使用选项 2，如果您查看 projectA 的历史记录，您无法判断对库所做的更改何时影响了项目。事实上，projectA 的同一个修订版可能有一天会起作用，而下一天就不会起作用，因为库已更改。获得告诉您更改的历史记录的唯一方法是查看完整的历史记录，其中还将包括 projectF 和 libraryX 的完全不相关的更改，从而使您很难看到有用的信息。
使用选项 1，projectA 的历史中有一个修订告诉它使用新版本的库。更改不会神奇地发生 - 当您明确表示要使用新版本的库时。这通常是一个更加稳定的环境。
【讨论】：
git svn 真的很难。
通过最近的 CVS 到 SVN 切换，我们决定在两者之间做一些事情：将相关项目组合在顶层，主干/标签/分支在下面，项目在此之下。
之所以这样做，是因为在这个地方，许多项目相互关联，并且经常被标记、分支等。
【讨论】：