只是好奇你的命名约定是什么：
存储库名称 分行 标签
目前，我们在SVN中采用了以下标准，但希望对其进行改进：
现在，说到这里，我很好奇每个人不仅要处理他们的存储库命名，还要处理他们的标签和分支。例如，您是否为项目名称使用了驼峰案例结构？
那么，如果您的项目类似于Backyard Baseball for Youngins，那么您如何处理？
这似乎相当微不足道，但这是一个问题。
如果您使用功能分支范例，您如何命名功能分支？功能本身用简单的英语后？某种版本控制方案？即假设你想为后院棒球应用添加功能，允许用户添加自己的统计数据。你会怎么称呼你的分支？
等
或者：
如果你去版本路线，你如何关联版本号？似乎功能分支不会从版本控制架构中受益太多，因为1个开发人员可能正在处理“用户添加统计信息”功能，而另一个开发人员可能正在处理“管理添加统计信息”功能。这些分支版本如何命名？他们最好是：
一旦它们合并到主干中，主干可能会适当增加？
标签似乎从版本号中受益最多。
话虽如此，您如何将您的项目版本（无论是主干，分支，标签等）与SVN相关联？即作为开发人员，您如何知道1.1.1具有管理员添加统计信息，以及用户添加统计功能？这些描述和链接如何？标签在每个标签中都有发行说明是有意义的，因为它们是不可变的。
但是，是的，你的SVN政策是什么？
答案 0 :(得分：6)
我用的是 主干，标签，分支模型。
Trunk：应始终保持稳定状态。 （不一定是可释放但稳定的，因为没有编译器错误）我通常会进行微小的更改和新功能，这些功能很小，可以在不到一天的时间内完成。如果我要开发需要几天的东西并且签到会使主干处于不稳定状态，我将创建一个分支。
分支机构用于功能开发，可能会使主干处于不稳定状态。它还用于“测试”新功能和想法。我确保做一个trunk来分支更新合并，以保持trunk中的最新开发与我的分支同步。
标记：适用于我希望快速返回的代码的发行版或稳定版本。通常，我将这些用于模块或应用程序的特定版本（1.00）。我尽量不对标签进行任何签到。如果存在错误，那么这些更改将在主干中进行，并将在下一个版本中进行。我做的唯一例外是紧急错误。这意味着标签已经正确QA并且非常稳定。
答案 1 :(得分：1)
我在存储库根目录下有 trunk ，分支，标记和工作区。
所有内容都在一个存储库中，每小时/每天/等。备份。所有步骤（如分支，标签，合并和构建）都是为了方便和稳定而编写的（脚本检查存储库一致性）。
仅允许对二级目录进行分支/合并，并且仅完成合并，而不是单个文件/目录（例如分支/ LDN_FSHCHPS_REL_2010 - ＆gt; workspaces / WS_345）以启用自动合并并避免子树合并信息的问题（并且当它们发生时也可以简化合并问题的根本原因）
答案 2 :(得分：1)
驼峰？不，我们不对名称施加任何限制，除了不鼓励使用空格。内容是重要的，而不是演示。只要名称明确定义了它的作用，我们就很高兴。
我认为您可以做出的最大改变是将所有项目放在顶层的单个回购中。
我们不使用分支或标签目录，因为我们有数百个项目，每个项目被划分为版本化组（即我们有一个版本化的基础平台，并且每个基本版本号下面都有很多插件）
例如：
base v1
+--- moduleA
+----moduleB
base v2
+--- moduleA
+----moduleB
我们已经考虑过在每个模块目录下放置一个标签分支，但我们几乎总是处理头版本，所以它对我们来说不是问题。我们会定期将旧版基础版模块的更改合并到新版本中 - 例如，对基础v1更改模块A，更改将合并到基础版v2的模块A中。除非必要，否则我们不会倒退。
每个模块都有一个发行说明，用于描述版本号和更改。日志注释中包含一些描述和版本号。这使得很容易获得以前的版本，而不必拥有许多唯一命名的标记分支。如果我们确实开始使用标记分支（已被建议）然后我们将完整路径副本复制到/ tags目录中），我们仍然会合并到单个标记分支并添加标记发布号的日志注释，我们只是有太多的模块来管理它们作为每个分支1个标签文件夹。不，我们永远不会对历史修订进行更改 - 如果客户需要新功能，他们必须升级到最新版本（在更改基础平台版本之前这绝不是问题）
我们也不使用分支，因为我们倾向于处理每个模块的头版本，如果我们确实需要一个主要变更的分支，我们将在基础分支，所以我们创建一个“基础v2 - 性能”分支和分支一切。这样可以很容易地将大量更改组合在一起，因为它最适合我们。分支单个模块会在回购中产生太多的混乱 - 因为我们有几百个，如果我们每个模块都有分支，就很容易丢失它们。
是的，我们在主干上进行了更改，但这对我们的工作流程来说没问题 - 在他们准备好之前，事情不会得到承诺。对旧版本进行的所有更改仅仅是错误修复，而且我们有太多的模块可以在完整的dev-test-release周期中管理它们。我们修复，如果它被证明是一个糟糕的修复，我们再次修复。我们有时会为更大的开发更改此方法，并在分支文件夹（在根目录下）创建分支。分支路径重新创建原始模块的路径（因此很容易分辨出它是什么，并且合并回来就像在路径开头更改/分支到/ trunk一样简单。）
我们在这个系统中遇到的唯一问题是我们将一个模块放在一个Web应用程序的项目中（redmine）。我们希望为模块的所有版本都有一个redmine项目，但是我们的布局使得向存储库提供root变得有点困难。如果我们可以将repo路径与redmine中的每个版本相关联，那么这个限制就会消失。
它不一定对每个人都是最好的，我建议更多地使用分支，但这对我们有用（部分原因是我们在以前的源代码控制系统中工作的方式是“安全的”并且不支持支链/合并）。
答案 3 :(得分：-2)
目前，我们正在使用SVN的以下标准......
通常，标签是可变的。标记发布的原因是，您可以在主干上继续开发时应用错误修复。当然，必须将相同的错误修复应用于主干。
所以，如果您的项目类似于Youngyard的Backyard Baseball，那么您如何处理？
我们是一家Java商店，所以我们所有的项目都名为gov.bop.project。 :-) Subversion适用于任何名称。
如果您使用功能分支范例，您如何命名功能分支？
我们使用事件报告系统生成的号码。这有助于审计。
标签似乎从版本号中受益最多。
我们发现yyyymmdd日期在很长一段时间内工作得更好。