我们是否始终遵循将分支，标签和主干目录放在Subversion存储库顶层的约定？最近，我不再打扰了，也没有发生任何不好的事情(尚未发生)！

如果需要创建目录树，应该可以在其中移动目录树。我会在以后惹麻烦吗？

解决方案

我们是否尝试过分支或者标记？在那之前，没有问题。但是，使用branchs，tags，trunk约定的另一个好处是-a约定。人们希望看到这一点，因此他们知道需要分叉时该怎么做。

不会，已将这种方法用于当前队列中的项目。尽管该概念非常有效，但似乎浪费的时间比实际节省的时间更多。

这取决于项目的规模。我们有一些相当大的东西(用git授予，但概念相同)。每个开发人员都使用他/她自己的分支，还有一个测试和主线分支。我们还标记了发行版，如果有特定于版本的修复程序，则会创建一个分支，以便可以轻松集成这些修复程序。

这种设置具有优点：在开发过程中，我们不会互相弄乱头发。但是不利的是，我们需要一个集成商将来自开发人员分支的提交放入测试分支，然后再提交给主线。

如果项目很小，那么这只是开销，但是我们永远都不知道项目会有多大。

你至少有一个行李箱吗？如果不是，那么当我们确实需要分支或者标记时，我们将必须将它们与实际的代码/内容一起放在根项目目录中。 kes！

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

对于那些说"以后再做，不要浪费时间，等等……"的人，老实说，在项目一开始就创建它们会产生多少开销？ 2分钟，顶部？那为什么不这样做呢？即使我们最终只需要在5次分支1次，以后再移动所有内容都将花费更长的时间，我仍然认为从分支，标记，主干结构开始使用的时间会更少。

我刚刚开始真正使用约定，并且我同意Danimal。如果我们在质量保证中拥有一个版本，在生产中拥有另一个版本，并且在疯狂的新实验功能开发中拥有另一个版本，那么在这些版本之间快速来回切换是很好的。

正如我在Subversion存储库中的"分支"，"标签"和"主干"是什么意思中所说的那样，由于分支和标签相同，因此我们不必遵循任何约定，而必须遵循自己的约定。
特别是对于具有顺序开发的小型项目(即，无需在当前开发，维护旧版本，探索替代框架之间进行并行工作……)

通常，我会将中继保留在存储库的根目录中，并且仅在确实需要创建分支标签的情况下才将其移动到Trunk文件夹中。我认为，使用SVN，只要结构合理，就可以在以后更改需求时重新安排它。

我在每个项目上都使用主干，标签和分支。认真地说，创建项目时创建两个额外的目录有多困难。遵循约定只是为了保持一致性有一些好处。我发现我有很多标签(在开发人员环境之外对应用程序的每次推送都会进行版本控制和标记)。我没有那么多分支机构，因为我通常不与不信任提交审核的人一起工作。因此，通常当我获得分支时，这是因为我通常将代码库永久拆分给不同的客户端。一旦代码变得不可调和，我通常会停止分支并将其移至其自己的主干。

最近，我使用了更加专注于敏捷性的模型，我们可以在这里看看。

在版本控制中遵循某些策略，甚至使用定义良好的模型也要非常重要，代码版本本质上会导致我们犯错，混乱的合并以及所有不良的事情，因此请小心。

该模型负责每个存储库的职责，并且不允许我们重叠生产，交付和基础建设代码所在的位置。

我遵循公约有多种原因

• 使用b / t / t约定的参考资料和过程可以立即应用于svn回购结构。
• 熟悉该约定的所有加入该团队的开发人员的学习曲线都很少，可以习惯svn repo结构。
• 当树干和分支机构具有直接而明显的好处时，只有当我们必须遍历历史和日志以覆盖我们或者公司资产时，我们才意识到保持一致的标记过程的好处。

简而言之，公约为什么是一件好事可能不是立即显而易见的，但是当我们需要帮助，建议或者某种管理上的疯狂时，它便成为了众所周知的天赐之物。

我喜欢将分支用于"小型项目"，以进行概念的简单证明。它快速，简单，通常有助于跟上主要项目。我将概念证明放在branchs目录中，因为它不是主项目的一部分，但对项目很有价值。

就像其他人提到的那样，我将标签用于发布。我执行的大多数版本都是版本，因此通常只包含该软件包的zip文件或者该版本的安装程序。

快速的答案是"做最适合程序的事情"。

正如Danimal所说，branch / trunk / tag的结构是一个约定。但是，我不同意重要的是b / t / t的位置，而仅仅是它们的存在。

我们应该拥有的地方显然是为分支机构指定的，某个地方为主干指定的，为标签相同的。它们的确切位置在很大程度上取决于存储库的结构和所保存文件的性质。

例如，如果我们将多个项目保留在一个存储库中，则可能会发现在项目下创建b / t / t目录更为有意义。如果项目中有不同的模块，则应在模块目录下创建b / t / t。

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

否。不是最后3个工作情况。我与需要编写，修复和调用处理脚本的非程序员合作。编程大多是随便的，偶尔会做得更深或者更大。不会遵循大型软件开发人员的做法。标准存储库术语可能与我们工作的领域中使用的术语冲突。因此，我们组成了自己的存储库目录。

在非常简单的环境中，我们可以摆脱SVN信息库顶部的分支，标签，主干的麻烦。例如，如果我们正在使用SVN进行大学作业，那么在将代码发布给客户(标记作业的人)之后，我们就不必担心代码更改，因此我们可以明智地省去分支，标签，主干，只有一种结构。 (实际上，整个事情就是"行李箱"。)

另一方面，如果我们一直在管理已部署到700个不同站点的代码，并且这些代码分散在不同的产品线中，那么我们将在结构顶部附近不使用"分支，标签，主干"是很疯狂的(在走BTT路线之前先拆分产品是明智的选择)，因为我们将需要知道什么代码去了哪里，并且能够将主要的重写活动(我们在主干中所做的事情)现场修复程序可以帮助站点解决当前的问题(先在分支机构中完成，然后合并到主干中)。并且，如果我们希望能够回答"为什么我们推出1.2.3补丁后Foobar为什么停止工作？"的问题那么标签是必不可少的。

过去，我已经编写了一些工具来使SVN的某些部分自动化。创建基本存储库就是其中之一。步骤1：创建一个空的存储库。步骤2：创建主干，分支和标签文件夹落实步骤3：将挂钩脚本复制到新存储库

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