你使用branches/tags/trunk约定吗?


7

您是否始终遵循将分支,标记和中继目录放在Subversion存储库顶级的约定?最近,我已经停止了烦恼,并没有发生任何不好的事情(还)!

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

12

您是否尝试过分支或标记?在此之前,这没有问题。但是,使用分支,标签,中继线约定的另一个好处就是它正是这样一个约定。人们期望看到这一点,所以他们知道在需要分岔时该怎么做。

  0

不,这些存储库中的标签非常少,因为它们恰好用于文档和项目管理,而不是主动软件开发。 23 9月. 082008-09-23 20:00:24


0

不,已经放弃了目前队列中的项目。虽然这个概念看起来非常有效,但它似乎浪费的时间比在实践中节省的时间要多。

+2

直到您需要创建分支或标签发布。此时,您将浪费数小时的开发人员努力来移动现有的代码库。更容易花30秒在开始时创建这些目录。 23 9月. 082008-09-23 19:54:12

  0

不好意思,根据需要不需要几个小时就可以创建分支或标记... 23 9月. 082008-09-23 19:56:53

  0

不,不过,一旦将代码从根移动到主干,您将有大量开发人员和自动化进程指向无标签 23 9月. 082008-09-23 20:21:12


1

这取决于项目有多大。我们有一些东西(在git中授予,但概念是相同的),这是相当大的。每个开发者都使用他/她自己的分支,有一个测试和主线分支。我们也为这些版本添加标签,如果有特定于版本的修补程序,则创建一个分支,以便可以很容易地集成修补程序。

这种设置具有以下优点:在开发过程中我们不会相互挤对方发。但缺点是我们需要一个集成者将开发者分支提交到测试分支,然后再到主线。

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

  0

标记在Git中至少是有用的 - 你可以看到一个提交是在哪个标签之前/之后,它们作为提交的助记符等等。在Subversion中,标签是二等公民,并且完全浪费时间。你不能做“svn log -r(tag-name)”或其他。即使CVS标签也更好。 23 9月. 082008-09-23 19:49:52

  0

SVN将所有内容视为一个目录。为了标记分支,您将其复制到./tags/目录中的目录中。同样适用于SVN中的分支。在git中,分支和标签是相互依赖的并且已经做好了 23 9月. 082008-09-23 22:14:00


0

你至少有一个后备箱?如果不是的话,当你需要分支或者标记时,你将不得不把它们放在你的根目录下,与实际的代码/内容一起。哎呀!

编辑:我想你可以创建一个trunk文件夹,然后将所有物体,然后创建分支等...

对于那些说:“只是做了以后,不要浪费时间,等..“说实话,在你的项目开始时,它会创造多少开销? 2分钟,上衣?那么为什么不就这么做呢?以后移动所有东西需要更长的时间 - 即使您最终只需要5次分支1次,我仍然认为从分支,标签,中继线结构开始,您会花费更少的时间。

  0

现在不是创建它们的时候了,它需要在日常使用中输入额外的路径元素,这让我很恼火! ~~~ 23 9月. 082008-09-23 19:50:36

  0

为什么不使用几个SVN前端之一(IDE集成,TortoiseSVN等)? 23 9月. 082008-09-23 19:52:07


1

我刚开始实际使用约定,我同意with Danimal。如果你有一个QA版本,另一个在生产中,另一个在疯狂的新实验功能开发中,那么很快就能在它们之间来回切换。


0

正如我在What do "branch", "tag" and "trunk" mean in Subversion repositories?中所说的那样,由于分支和标记是相同的,因此您没有义务遵循任何约定,而是您自己的约定。
特别是对于一个具有顺序开发的小型项目(即不需要在当前开发之间的并行工作,维护旧版本,探索替代框架,...)


0

我通常会将我的主干保留在如果我真的需要创建分支的标签,那么只能将它移动到一个Trunk文件夹中。我认为,只要你的结构是合乎逻辑的,你应该没有问题,如果你的需求改变,以后再重新安排。


0

我在每个项目上都使用trunk,tags和branches。严重的是,在创建项目时创建2个额外的目录是多么困难。遵循这一惯例只是为了保持一致性,这是有益处的。我发现我有很多标签(每次在开发者环境之外推送应用程序都会得到版本和标签)。我没有这么多的分支机构,因为我通常不会在审查之前与不信任的人一起工作。所以,通常当我获得分支机构时,这是因为我有永久性的代码分割 - 通常是针对不同的客户端。一旦代码变得不可调和,我通常会停止一个分支并将其移至自己的主干。


0

最近我使用的模型更集中于敏捷,你可以看看here

在版本控制中遵循一些策略非常重要,即使使用明确定义的模型,代码版本本质上也会导致您犯错误,混乱合并以及所有不好的东西,所以要小心。

该模型为每个存储库提供职责,并且不会让您在生产,交付和在建代码所在的位置重叠。


0

我遵循的原因很多

  1. 参考材料和程序,使用B/T/T约定可以立即应用到你的svn的结构的惯例。
  2. 所有进入团队熟悉惯例的开发人员都有一个最小的学习曲线来适应您的svn回购结构。
  3. 作为中间人&作为分支机构的直接和显而易见的好处,只有当您不得不通过历史和日志来覆盖您或您的公司时,才会意识到维护一致标记过程的好处。

简而言之,为什么这个约定是一件好事,但是当你需要帮助,建议或者一些管理疯狂时,它会成为谚语的天赐之物。


0

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

和其他人一样,我使用标签发布。我所做的大多数版本都在版本中,所以我通常只需要一个包或版本的安装程序的zip文件。


2

快速回答是“尽最大努力适合您的程序”。

由于Danimal说branch/trunk/tag的结构是一个约定。但是,我不同意这是重要的b/t/t的位置,仅仅是它们的存在。

你应该有什么地方显然是指定为分行,某处指定为您的树干和相同的标签。它们的确切位置取决于您的存储库结构以及您所保存的文件的性质。

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

问问自己什么是最大的逻辑块将是你想要分支和指导。


0

不是最后3种工作情况。我与需要编写,修复和调用处理脚本的非程序员合作。编程主要是随意的,有时会进行更深入或更大的工作。没有期望遵循大量软件开发人员的做法。标准仓库术语可能与我们工作领域中使用的术语冲突。因此,我们构建了自己的仓库目录。


0

在一个非常简单的环境中,您可以远离SVN存储库顶部的分支,标记,树干。例如,如果您使用SVN进行大学作业,那么在将代码发布给您的客户(标记作业的人员)之后,您不会对代码的更改感到担忧,因此您可以明智地省略分支,标签,树干,只有一个结构。 (实际上,整个事情就是'后备箱')。

另一方面,如果您一直在管理部署到700个不同站点的代码并将其分散到不同的产品系列中,那么您应该疯狂的时候不要在结构顶部附近使用“分支,标签,树干”(在BTT路由之前有一个明智的例子来分割你的产品),因为你需要知道哪些代码去了哪里,能够将现场修复中的主要重写活动(您在干线中执行的操作)与现场修复分开,以帮助网站解决即时问题(您在分支中执行操作,然后合并到主干中)。如果你想回答这个问题:“为什么Foobar在我们推出补丁1.2.3时停止工作?”那么标签是必需的。


1

我已经写过工具来自动化某些SVN片段。创建一个基本的存储库就是其中之一。第1步:创建一个空的存储库。步骤2:创建中继线,分支和标签文件夹 - 提交步骤3:将挂钩脚本复制到新存储库

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