这个svn结构有多好？

Question

上面是我计划用于组织中java项目的结构模拟。你们怎么看待它？它看起来像传统吗？另外，如果你使用project1，在标签下，你可以看到，1.0.1,1.0.2等等 - 这些是发布后发布的发布标签。现在，Dev分支下会存在哪种标签？什么时候会被创造？我应该在DevBranch下为每个开发人员创建分支吗？我很困惑。

Answer 1

你们怎么看？

不行。通常，branches 不会包含更多tags，trunk，branches。 Branch与trunk类似，但是是并行开发流。通常，您可以通过copy或trunk或其他tag branch创建分支。除此之外没关系。

它看起来像传统吗？

是的，确实如此。

现在，Dev分支下会存在哪种标签？

按标签表示名称。您可以为它们提供一些描述性名称..例如或project1_new_caching_mechanism或project1_1.1_spot_fixes - 表示可能会从版本1.1标记中复制这些名称以修复发布中的某些问题。当您释放此分支时，您希望将这些修复程序合并到其他并行运行的分支和主干。

什么时候会被创建？

每当您找到并行开发方案时。就像你想通过负载测试来改进性能并在不妨碍主要开发分支的情况下向其添加改进的代码。或者是现场修复。或者用于功能替换..或多版本支持。

我应该在DevBranch下为每个开发人员创建分支吗？

否。 SVN是集中存储库...（与Git不同），任何SCM的目的是允许多个开发人员同时处理它...你将通过分离来藐视目的每个开发者的回购。

Answer 2

我建议：

repo--tags
    --branches
    --trunk--project1
           --project2
           --project3

...如果您想同时标记和分支所有项目

或者这个：

repo--project1--tags
              --branches
              --trunk
    --project2--tags
              --branches
              --trunk
    --project3--tags
              --branches
              --trunk

..如果您希望能够为每个项目单独进行标记和分支。

不要嵌套标签/分支/中继，它在概念上没有意义。

分支属于开发周期（即myproject_1_1_sprint_1），标记标记项目在给定时间点的状态（即myproject_1_1_RC03，表示版本1.1的候选版本3）。请注意，这些纯粹是按惯例确定的概念差异。 SVN在分支和标签之间没有技术差异，它们都被称为项目目录结构的“cheap copies”。

请参阅描述GIT成功分支策略的this excellent article，该策略也适用于SVN等其他版本控制系统。

Answer 3

如果我没有完全错误，我认为在Dev（和Experimental）之下，应该没有分支/标签/中继。如果你想创建dev分支的版本，你可以把它放在这里：

/svn/projects/project1/tags/dev-1.0.1

或类似的东西。例如。 Dev和Experimental就像每个分支的trunk文件夹。如果你想从Dev创建一个分支你可以称之为Dev2，但我认为这使得它比需要的更复杂。

此外，我根本不会使用Dev，而是执行属于主干中Dev开发的所有内容

/svn/projects/project1/trunk

但是可能有充分的理由要有一个额外的Dev分支。

Answer 4

对我来说很好看。如果您需要使用Maven或Ivy自动化它，我也会添加test。

Answer 5

您需要阅读SVNBook (Version Control with Subversion)。我不认为标签属于那里。

我不喜欢你的开发，实验等等。这些是/分支机构的意思。当你完成后，你要么将它们合并到/ trunk，要么只是挂在树枝上。

标签适用于您进入生产阶段，并且您希望创建一个只读的，永远不会被修改的分支副本。

您可以选择安排存储库：

1. 一个存储库，其下面是/ trunk，/ branches和/ tags，以及这些存储库下的项目。
2. 一个存储库，下面有多个项目，每个项目都有自己的/ trunk，/ branches和/标签。
3. 每个项目一个存储库，每个存储库都有自己的/ trunk，/ branches和/ tags。

Answer 6

您似乎希望拥有“每个功能的分支”，其中每个功能或开发人员都有自己的分支，并将其提升为功能完成的主干。如果是这样，您可能需要查看像mercurial或git这样的分布式版本控制系统。

如果你想使用svn（并且你可能有充分的理由），那么我建议有两个不同的branch目录：一个dev-branches用于为功能，开发人员或概念证明创建的分支，和branches用于生产代码的分支（能够在开发过程中修复生产中的错误），并同时划分Experimental和Dev

Answer 7

就个人而言，我喜欢使用分支机构进行标签号码的持续工作，以及静态快照的标签。这样，当有时间冻结1.0.1的版本时，我将主干复制到branches\1.0.1，当我在最终稳定/错误修复期间构建版本时，我在{{{{}}中制作了不可编辑的副本1}}，tags\1.0.1.5等

关键是制作一个快速脚本，检查父目录是否为tags\1.0.1.11目录，然后重新配置子目录，使其在创建后不具有写访问权限。否则，您的标签会移动标签，这会破坏静态标记的目的。

Answer 8

我会简化你所拥有的。 “DEV”应该是你的主干。您应该从项目级别开始，每个项目都应该有一个标签，主干和分支目录。

projects/<project>
    tags
    trunk
    branches

如果你需要像上面提到的“Experimenal”和“Client-1”这样的东西，它应该是一个基于trunk的分支

projects/<project>/branches/experimental
projects/<project>/branches/client-1

同样，标签应该在一个公共位置，您可以使用文件夹来组织它们：

projects/<project>/tags/experimental
projects/<project>/tags/client-1

这有很多原因

1. 用户的可预测性==＆gt;有人应该能够预测你的svn 结构，无论他们在哪个模块。
2. 钩子的可预测性==＆gt;你的钩子只保留标签 真的需要一个可预测的结构，以避免存在 过于复杂。
3. 合并==＆gt;你的“实验”和 “client-1”分支应该从你的主干分支出来，这样就可以了 易于始终将主干功能合并到这些分支。 同样，您也可以合并功能，只要它们具有 从树干分支。

而且我确定还有更多，但这些就是那些突然出现在我身上的东西。