Question

我对'标准'svn布局

最熟悉（也很舒服）

+---trunk
|   +---file1
|   +---file2
|   \---...
+---tags
|   +---0.0.1
|   +---0.1.0
|   \---1.0.0
\---branches
    +---developer1
    |   +---file1
    |   +---file2
    |   \---...
    +---developer2
    \---developer3

我的同事在版本控制系统中有不同的背景，宁愿有这种布局

+---trunk
|   \---branches
|       +---developer1
|       |   +---file1
|       |   +---file2
|       |   \---...
|       +---developer2
|       \---developer3
+---file1
+---file2
\---...

这完全是错误的方式，但我无法给出充分的技术理由，为什么我们会遇到第二种（当前）方法的问题。

我有一种感觉--mergeinfo不喜欢这种布局，但我们的服务器运行1.4，我不确定很快就会升级。

Answer 1

第二种布局的主要问题是你不能只是在不明确排除分支的情况下检出主干。使用（默认）布局，您可以选择签出中继或开发分支。

您不会遇到两者的技术问题。

Answer 2

你是对的，他们不是。这是标准结构，它是标准结构的原因。

他们的主要问题是他们将不同版本的代码混合在一个目录中。 trunk目录似乎包含项目中的两个文件以及branches目录。这意味着合并到该目录或从该目录移出将总是很奇怪，并且查看该目录的日志将始终混合分支中的更改和主干中的更改。

标准布局的好处是每个分支，标签或主干都是项目的自包含副本，因此它们之间的合并将起作用，检查它将为您提供正确的内容等。

Answer 3

等等，所以如果你检查出trunk，你也会把你所有的开发者分支放在同一个文件夹中？是对的吗？即使你只想要主干，你也必须同时抓住所有分支？（此刻有点不适，希望我能正确理解）

太可怕了！在任何体面的大小项目中，结账程序突然在带宽，存储和时间方面大量膨胀。

这会杀死存储库的部分结账（即只检查1个文件夹及其内容）的任何好处！

我听说过一家使用SVN而不是GIT的游戏公司，因为他们的完整存储库大小很多，他们需要部分结账，所以工作人员可以处理它。

编辑添加：

此外，您为SVN获得的所有工具都希望事物处于您喜欢的布局中。当然，您可以为您的同事布局配置它们，但为什么要通过这种麻烦？

另外，这肯定意味着如果你想创建一个新的分支，你就无法做到

svn cp .../trunk/ .../branches/mine

没有做

svn rm .../branches/mine/branches/<everyone elses>

之后，有点笨拙没有？

Answer 4

Subversion Book建议your layout。然而，这只是我理解的建议，尽管有些程序可能（错误地）要求或承担它。

对于Subversion来说，这些只是目录，无论你如何命名它们或放置它们的位置都没关系，但你可能正确的是你的同事的布局在合并时会很麻烦，因为你的分支会低于中继线。

Answer 5

决定应基于该工具的运作。 SVN支持分支作为repo树的不同部分。在第二个布局中，与trunk对等的file1和file2是什么？它们似乎不属于合理的工作树。

我对第二种布局的问题是文件在/ trunk / branches / blah / blah中。他们在行李箱或树枝上吗？这是什么意思？

你需要清楚地了解trunk和branch的含义，并找出SVN结构将支持这些含义。

正如其他人所指出的，你不想把树枝放在树干里面。为了与svn一起使用，您的结构不应该将工作树的根嵌套在另一个工作树中。

这个svn repo结构有什么问题吗？

5 个答案: