logo标签列表

Subversion项目结构？

svnversion-control
3
创建subversion项目时，每个单独的项目是否应该包含自己的主干（trunk）、分支（branches）和标记（tags）目录？例如：
MyProject 1 - branches - tags - trunk
MyProject 2 - branches - tags - trunk
等等...
还是说，每个项目本身应该放在一个全包含的结构中？例如：
branches tags trunk - MyProject 1 - MyProject 2 等等...
重复的问题，其中包括https://dev59.com/NkbRa4cB1Zd3GeqP0nht#519090 - anon
4个回答
4

如果需要，选项1更容易拆分到不同的源代码控制中，因此我更喜欢这个选项。

对我来说，第一个选项在管理项目范围的权限方面似乎更容易。

2

两种方法都很常见，但第一种方法更为普遍。

更为常见的是为不同的项目设置单独的仓库——人们无法忍受在“他们”的仓库中有“不相关”的东西。

1
使用单独的存储库方法可以为每个项目配置单独的访问权限。在我看来不是推荐的做法，但可能有理由这样做。 - Treb
2
我个人倾向于选择选项1。这是因为选项2存在以下相当微妙的问题：
使用选项2时，通常会使您的工作副本与存储库结构匹配。这意味着您实际上要检出整个副本（或其部分，但在同一总体结构中）。
当涉及到依赖关系时，比如项目A和项目B引用库C，库中的更改与应用于这两个项目的更改之间没有控制。一旦将提交提交到库C的主干，所有使用它的项目都会收到此更改。这样做的净效果是您不敢更改库C，因为它可能会破坏其中一个项目。
使用选项1，您可以使用外部文件将库C的特定版本引入项目A和项目B中。事实上，如果需要，A和B可以使用不同的版本。
这意味着您可以随意更改库C，然后控制何时将更改应用于项目-根据需要测试和更改代码，并知道您正在升级到库的最新版本。如果升级存在基本问题，您可以继续使用旧版本，直到修复库中的问题。
另一种看待这个问题的方式是，对于选项2，如果查看项目A的历史记录，则无法确定库的更改何时影响了该项目。实际上，项目A的同一修订版可能在一天工作，但在另一天不工作，因为库已更改。您可以获得告诉您更改的历史记录的唯一方法是查看完整的历史记录，这也将包括项目F和库X的完全不相关的更改，使您想要查看的有用信息难以看到。
使用选项1，项目A的历史记录中有一个修订版，告诉它使用库的新版本。更改不会神奇地发生-只有当您明确表示要使用库的新版本时才会发生。这通常是一个更稳定的环境。
避免大量的检出和构建环境的稳定性，这两点都值得加1分。 - Michael van der Westhuizen
值得一提的是，选项2使用git svn变得非常困难。 - jason
1

最近进行了从CVS到SVN的转换，我们决定采用一种折中方案：将相关项目分组放置在顶层，下面是trunk/tags/branches以及这些项目。

之所以这样做，是因为在这个地方，许多项目彼此相关，并经常一起打标签、分支等。

2
非常好的解释。人们经常做事情是因为有人告诉他们该怎么做。关于哪些部分应该放入给定项目的关键决策应该是“它们是否会一起推广？”！ - Brad Bruce
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接