SVN分支和标签使用哪种命名约定？
我们公司正在为SVN分支机构和标签创build一个命名约定，而且我对使用分支/标签名称上只有date或内部编号的想法并不满意。
我认为我们需要的名字能够给这个道路所代表的东西带来更大的定义，正在做些什么努力等等。
你觉得/使用什么？
我总是在标签（通常是分支）前添加YYYYMMDD格式的date，然后描述标签或分支的用途。
例如，20090326_Release_v6.5或20090326_Post_Production_Update
这当然是标准的trunk / tags / branches层次结构。
date前缀可确保所有标签或分支以创build顺序显示，如果您通过一个大标签文件夹进行扫描，这将更有用，然后按说明进行sorting。 您会看到创build时间和原因的时间表（如小型日志消息）。
那么，分支是非常开放的，因为有几种不同的分支，它们的命名可以是非常不同的。
值得记住什么源代码控制给你。 标签名称不只是“v1.4”，而是“/CashCowProject/tags/v1.4”。 命名一个标签“/CashCowProject/tags/CashCowProject-v1.4”有点多余，那还会是什么？
版本控制还使您可以完全访问标签创build的date和时间。 版本控制也给你提交你应该使用的消息，特别是第一行。
考虑到所有这些信息，将一个简单的视图提供给所有您需要的信息并不困难，这些信息来自一致且适当的来源，例如：
CashCowProject v1.4 - 26 March 2009 : With Added whizzbang (more) v1.3 - 13 February 2009 : Best graphics! (more) v1.2 - 01 January 2009 : Upgraded security (more) 标签名称在这里唯一有用的是版本号。 如果你想把所有的信息都放在一个标签的名字里，这有点罗嗦，我敢打赌它看起来不太好。
对于function分支，在完成之后命名。 例如，我将我们的ORM从LINQ转移到SQL到NHibernate，并创build了一个名为“NHibernate”的分支。 一旦你完成了分支，并将其合并到主干中，你可以删除分支来保存将来的命名冲突。 如果你真的需要检索分支，你只需要回顾历史并恢复它。
如果你有一个分支相关的故事/报价/工作号码，我会把它附加到分支的名字，例如。 “NHibernate_429”，所以你可以很容易地引用它跟踪系统。 但是，我会一直用英语，因为这是人们在开发时更真实地提及的东西。
对于像标签这样的东西，很难说出你想要做什么，因为它取决于你正在标记的东西。 如果你正在标签发布，那么我会使用“发行XXXX”或类似的东西。 作为一个例子，你真的不会在意什么date或内部版本号。
我们所有的开发人员任务都进入了一个错误跟踪系统。 这个错误跟踪系统有与每个任务相关的ID。
因此，对于任何任务的分支名称，我们使用：
ticketId_TicketSubject
当分支包含多个ticketIds时，我们只需将它们合并到分支名称中：
ticketId1_ticketId2_Description
这样，如果你在一张票上，并且想要知道要build立哪个分支，你可以轻松地查找它。 同样，如果你想find你的分支构build票，你也可以很容易地find它。
对于标签，我们通过版本号本身进行标记。
至于每个分支的位置。 我们有这样的顶级层次结构：
/branches
/tags
/trunk
然后，我们所有的产品/项目都在每个子文件夹下。
/trunk/project1/
/branches/project1/TicketId_Description
我们使用什么（主要遵循公认的惯例）：
projectName | --trunk | --tags | --branches
在树干下，我们有主干。
在标签下，我们标记每个版本（内部版本，testing版本和客户版本）。 我们只使用版本号作为标签名称。
在分支下，我们发布的每个主要版本都有一个分支（在我们的例子中是XP迭代的结果）。 这些被命名为主版本（“v5.03”，“v6.04”）。 此外，我们有内部分支机构进行重大更改或特殊版本。 命名是自由forms的，这个名字应该告诉人们分支代表什么。 示例将是“workaround_customerA”，“module_x_reorg”等
我们给分支机构一个“.X”版本，标签有一个数字。
例如，分支是Foo-1.2.3.X，标签是Foo-1.2.3.1，Foo-1.2.3.2等
我们也有一个特殊的标签，Foo-1.2.3.0，这个标签在分支从trunk被创build之后立即生成，然后进行任何更改。 这样我们就可以随时将分支和标签区分到初始状态（因为几天后，主干可能会不同）。 这种做法使得合并变得容易一些，并且使分支中更改的代码变得更容易。
更好：
<projectname>_<Year>_<minor>_00
喜欢：
XYZ_14_01_00
