7

在此处输入图像描述

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

4

8 回答 8

5

你们怎么看？

不好。通常，branches 不包含进一步tags的 , trunk, branches。Branch就像trunk一个并行开发流。通常，您通过copying from trunkor from tagor from another来创建一个分支branch。除此之外没关系。

它看起来很传统吗？

是的。

现在，Dev 分支下会存在什么样的标签？

标签是指名称。你可以给他们一些描述性的名字.. like or project1_new_caching_mechanismor project1_1.1_spot_fixes-- 表示这可能是从发布1.1标签复制来修复发布中的一些问题。当您发布此分支时，您希望将这些修复合并到其他并行运行的分支和主干。

它们什么时候被创建？

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

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

不。SVN 是集中式存储库……（与 Git 不同），任何 SCM 的目的是允许多个开发人员同时处理它……您将通过为每个开发人员分离存储库来违背目的。

于 2012-08-08T15:38:07.490 回答
3

我建议这样做：

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 在分支和标签之间没有技术差异，它们都是项目目录结构的所谓“廉价副本”。

请参阅这篇描述 GIT 成功分支策略的优秀文章，该策略也适用于 SVN 等其他版本控制系统。

于 2012-08-08T20:28:30.283 回答
2

如果我没有完全错，我认为在开发（和实验）之下，应该没有分支/标签/树干。如果你想创建 dev 分支的发布，你可以把它放在这里：

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

或类似的东西。例如 Dev 和 Experimental 就像每个分支的主干文件夹。如果您想从 Dev 创建一个分支，您可以将其称为 Dev2，但我认为这会使它变得比要求的更复杂。

此外，我根本不会使用 Dev，而是做属于主干中 Dev 分支的所有事情

/svn/projects/project1/trunk

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

于 2012-08-08T15:34:18.350 回答
1

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

于 2012-08-08T15:28:14.280 回答
1

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

我不喜欢你的 Dev、Experimental 等。这些就是 /branches 的意义所在。完成后，您可以将它们合并到 /trunk 或直接挂在树枝上。

标签适用于当您投入生产并且您想要创建一个只读的、永不被修改的已发布分支的副本时。

您可以选择安排存储库：

  1. 一个包含 /trunk、/branches 和 /tags 的存储库，以及这些项目下的项目。
  2. 一个存储库下面有多个项目，每个项目下面都有自己的 /trunk、/branches 和 /tags。
  3. 每个项目一个存储库，每个存储库都有自己的 /trunk、/branches 和 /tags。
于 2012-08-08T15:35:02.860 回答
1

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

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

于 2012-08-08T15:39:11.993 回答
1

就个人而言，我喜欢使用分支来进行标记编号的持续工作，以及静态快照的标记。这样，当需要冻结 的发布时1.0.1，我会将主干复制到其中，并且当我在最终稳定/错误修复期间构建发布时，我会在、等branches\1.0.1中制作不可编辑的副本。tags\1.0.1.5tags\1.0.1.11

关键是制作一个快速脚本来检查父目录是否是tags目录，然后在创建子目录后重新配置子目录以使其没有写入权限。否则，您的标签是移动标签，这违背了静态标签的目的。

于 2012-08-08T15:39:38.740 回答
1

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

projects/<project>
    tags
    trunk
    branches

如果您需要上面提到的“Experimenal”和“Client-1”之类的东西，它应该是基于主干的分支

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

同样，标签应该在一个共同的地方，你可以使用文件夹来组织它们：

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

这有很多原因

  1. 用户的可预测性 ==> 无论他们在哪个模块中，都应该能够预测您的 svn 结构。
  2. 钩子的可预测性 ==> 保持标签只读的钩子确实需要一个可预测的结构，以避免过于复杂。
  3. 合并 ==> 你的“experimental”和“client-1”分支应该从你的主干分支出来，这样就可以很容易地将主干功能一致地合并到这些分支。同样，您也可以合并特征，只要它们是从主干分支出来的。

而且我敢肯定还有更多，但这些都是我突然想到的。

于 2012-08-08T15:47:43.033 回答