代码之家  ›  专栏  ›  技术社区  ›  Steve Pitchers D V Santhosh Kiran

你使用树枝/标签/树干惯例吗?

svn
  •  7
  • Steve Pitchers D V Santhosh Kiran  · 技术社区  · 16 年前

    你总是遵循将分支、标签和主干目录放在Subversion存储库顶层的惯例吗?最近,我已经不再打扰了,还没有发生什么不好的事情!

    如果需要创建目录树,应该可以移动它们。我是在为以后制造麻烦吗?

    15 回复  |  直到 16 年前
        1
  •  12
  •   Danimal    16 年前

    你试过分支或标记了吗?在那之前,没有问题。然而,使用分支、标签、主干约定的另一个好处是,这正是约定。人们希望看到这一点,所以他们知道在需要分叉时该做什么。

        2
  •  2
  •   Andrew Edgecombe    16 年前

    快速的答案是“做最适合你的程序的事情”。

    正如Danimal所说,分支/主干/标签的结构是一种惯例。然而,我不同意b/t/t的位置是重要的,仅仅是它们的存在。

    你应该有一个明显指定给树枝的地方,一个指定给你的行李箱的地方,以及一个同样指定给你标签的地方。它们的确切位置在很大程度上取决于存储库的结构和所保存文件的性质。

    例如,如果您将多个项目保存在一个存储库中,您可能会发现在项目下创建b/t/t目录更有意义。如果你的项目中有不同的模块,那么b/t/t应该在模块目录下创建。

    问问自己,你希望分支的最大逻辑块是什么,并以此为指导。

        3
  •  1
  •   terminus    16 年前

    这取决于项目的规模。我们有一些相当大的东西(当然,用git表示,但概念是一样的)。每个开发人员都使用他/她自己的分支,有一个测试和主线分支。我们还标记了发布版本,如果有特定版本的修复,则会创建一个分支,以便可以相当容易地集成修复。

    这种设置有优点:我们在开发过程中不会互相干扰。但缺点是,我们需要一个集成器将开发人员分支的提交放入测试分支,然后再放入主线分支。

    如果项目很小,那么它只是开销,但你永远不知道项目会有多大。

        4
  •  1
  •   Community CDub    8 年前

    我刚刚开始实际使用惯例,我同意 with Danimal 。如果你在QA中有一个内置,在生产中有另一个,在疯狂的新实验功能开发中也有一个,那么在它们之间快速切换会很好。

        5
  •  1
  •   Brad Bruce    16 年前

    我过去写过一些工具来自动化SVN的某些部分。创建基本存储库就是其中之一。步骤1:创建一个空存储库。步骤2:创建主干、分支和标签文件夹-提交步骤3:将钩子脚本复制到新存储库

    我的钩子脚本之一是确保标签目录中的项目不能被修改。这使得标签的含义与分支不同。

        6
  •  0
  •   Brian Knoblauch    16 年前

    不,对于目前正在排队的项目,已经放弃了这种方法。虽然这个概念似乎非常有效,但它似乎浪费的时间比实际节省的时间多。

        7
  •  0
  •   Community CDub    8 年前

    正如我在 What do "branch", "tag" and "trunk" mean in Subversion repositories? ,因为branch和tag是相同的,所以除了你自己的约定之外,你没有义务遵循任何约定。
    特别是对于具有顺序开发的小型项目(即不需要在当前开发、维护旧版本、探索替代框架之间进行并行工作……)

        8
  •  0
  •   Nick Higgs    16 年前

    我通常会将主干保存在存储库的根目录中,只有当我真的需要创建分支的标签时,才会将其移动到主干文件夹中。我认为使用SVN,只要你的结构是合乎逻辑的,如果你的需求发生变化,你以后重新安排它应该没有问题。

        9
  •  0
  •   Chris Marasti-Georg Scott Weinstein    16 年前

    你至少有一个行李箱吗?如果没有,当你确实需要分支或标记时,你必须将它们放在你的根项目目录中,与实际的代码/内容放在一起。诶呀

    编辑:我想你可以创建一个主干文件夹,然后将所有内容移动到其中,然后创建分支等。。。

    对于那些说“以后再做,不要浪费时间等等……”的人来说,老实说,在项目开始时创建它们需要多少开销?最多两分钟?那为什么不直接做呢?稍后移动所有内容需要更长的时间——即使你最终只需要五分之一的分支1,我仍然认为从分支、标签、主干结构开始,你会用更少的时间。

        10
  •  0
  •   mrankin    16 年前

    我在每个项目中都使用主干、标签和分支。说真的,在创建项目时创建2个额外的目录有多难。为了保持一致性,遵循惯例有一些好处。我发现我有很多标签(每次在开发人员环境之外推送应用程序都会进行版本控制和标记)。我没有那么多分支机构,因为我通常不会在审查前与我不信任的人合作。所以,通常当我得到分支时,这是因为我对代码库进行了永久性的拆分——通常是针对不同的客户端。一旦代码变得不可调和,我通常会停止一个分支并将其移动到自己的主干中。

        11
  •  0
  •   paulosuzart    16 年前

    最近我使用了一个更专注于敏捷的模型,你可以看看 here .

    在版本控制中遵循一些策略非常重要,因为即使使用定义良好的模型,代码版本本质上也会导致你犯错误、混乱的合并和所有这些坏事,所以要小心。

    该模型为每个存储库指定了责任,并且不允许您在生产、可交付和在建代码的位置重叠。

        12
  •  0
  •   flungabunga    16 年前

    我遵守惯例有很多原因

    1. 使用b/t/t约定的参考资料和程序可以立即应用于您的svn回购结构。
    2. 所有加入团队并熟悉惯例的开发人员都有一个最小的学习曲线来适应你的svn仓库结构。
    3. 哪里有行李箱和;分支机构有一个直接而明显的好处,只有当你不得不浏览历史和日志来掩盖你或你的公司时,你才会意识到保持一致的标记程序的好处。

    简而言之,为什么大会是一件好事可能并不明显,但当你需要帮助、建议或一些管理疯狂时,它就会成为众所周知的天赐之物。

        13
  •  0
  •   nyxtom    16 年前

    我喜欢将分支用于“迷你项目”,以进行简单的概念证明。它快速、简单,通常有助于跟上你的主要项目。我将概念证明放在branches目录中,因为它不是主项目的一部分,但对项目有价值。

    正如其他人提到的,我使用标签发布。我做的大多数发布都是版本,所以我通常只有一个包的zip文件或版本的安装程序。

        14
  •  0
  •   DarenW    16 年前

    不,不是最后三种工作情况。我与需要编写、修复和调用处理脚本的非程序员一起工作。编程大多是随意的,偶尔会有更深入或更大的工作。没有人期望遵循大软件开发人员的做法。标准的存储库术语可能与我们工作领域使用的术语相冲突。因此,我们创建了自己的存储库目录。

        15
  •  0
  •   Nick Argall Nick Argall    16 年前

    在一个非常简单的环境中,您可以省略SVN存储库顶部的分支、标签和主干。例如,如果你在大学作业中使用SVN,那么在代码发布给客户(标记作业的人)后,你就不会太担心代码的更改,因此你可以明智地省去分支、标签、主干,只使用一个结构。(实际上,整件事就是“树干”。)

    另一方面,如果你一直在管理部署到700个不同站点的代码,并且这些代码被拆分到单独的产品线中,那么不在结构顶部附近使用“分支、标签、主干”是疯狂的(在BTT路线上拆分产品是明智的),因为你需要知道哪些代码去了哪里,并且能够将主要的重写活动(你在主干中做的事情)与局部修复分开,以帮助有即时问题的站点(你在分支中做,然后合并到主干中)。如果你想回答“为什么在我们推出1.2.3补丁时Foobar停止工作?”这个问题,那么标签是必不可少的。