为subversion创建项目时，每个项目是否都包含自己的trunk，branches和tags目录？例如
MyProject 1
- 分支机构
- 标签
- 行李箱
MyProject 2
- 分支机构
- 标签
- 行李箱
等...
或者每个项目本身都应该进入一个无所不包的结构吗？例如
分支
标签
树干
- MyProject 1
- MyProject 2
等...
答案 0 :(得分：4)
如果需要，选项1可以更简单地分成不同形式的源代码控制，因此我更喜欢它。
在我看来，在第一个选项中管理项目范围的权限会更容易。
答案 1 :(得分：2)
这两种方法都很常见，但第一种方法更常见。
更常见的是为单独的项目设置单独的存储库 - 人们无法忍受在“他们的”存储库中存在“无关”的东西。
答案 2 :(得分：2)
我个人选择选项1.这是因为选项2存在以下相当微妙的问题：
使用option2，您的工作副本与存储库结构相匹配是很常见的。这意味着有效地检查整个副本（或部分副本，但具有相同的一般结构）。
这涉及到依赖项时的问题，例如projectA＆amp; projectB引用libraryC，库中所做的更改与应用于2个项目的更改之间无法控制。一旦提交到libraryC的主干，它就会被所有使用它的项目所接受。这样做的最终结果是你害怕更改libraryC，因为它可能会破坏其中一个项目。
使用option1，您可以使用externals将特定版本的libraryC引入projectA＆amp; amp;项目B。事实上，A＆amp;如果需要，B可以使用不同的版本。
这意味着您可以随意更改libraryC，然后控制何时将更改应用于项目 - 根据需要测试和更改代码，并且知道您正在升级到库的最新版本。如果升级存在根本问题，您可以继续使用旧版本，直到修复库的问题。
另一种看待这种情况的方法是，使用option2，如果查看projectA的历史记录，则无法确定何时对库进行的更改会影响项目。事实上，同一版本的projectA可能有一天而不是下一个，因为库已被更改。您可以获得告诉您更改的历史记录的唯一方法是查看完整的历史记录，其中还包括对projectF和libraryX完全无关的更改，从而使您难以看到有用的信息。
使用option1，projectA的历史记录中有一个修订版，告诉它使用新版本的库。这种变化不会神奇地发生 - 当你明确地说要使用新版本的库时。这通常是一个更稳定的环境。
答案 3 :(得分：1)
通过最近的CVS-to-SVN切换，我们决定介于两者之间：在顶层组合相关项目，在下面使用主干/标签/分支，以及下面的项目。
这样做是因为，在这个地方，很多项目彼此相关，并且经常被标记，分支等。