只是好奇你的命名约定是什么:
存储库名称分支标签
目前,我们在SVN中采用了以下标准,但希望对其进行改进:
现在,说到这里,我很好奇每个人不仅要处理他们的存储库的命名,还要处理他们的标签和分支.例如,您是否为项目名称使用驼峰案例结构？
那么,如果你的项目是这样的Backyard Baseball for Youngins,你如何处理？
这似乎相当微不足道,但这是一个问题.
如果您使用功能分支范例,您如何命名功能分支？功能本身用简单的英语后？某种版本控制方案？也就是说你想为后院棒球应用添加功能,允许用户添加自己的统计数据.你会怎么称呼你的分公司？
等等
要么:
如果你去版本路线,你如何关联版本号？似乎功能分支不会从版本控制架构中受益太多,因为1个开发人员可能正在处理"用户添加统计信息"功能,而另一个开发人员可能正在处理"管理添加统计信息"功能.这些分支版本如何命名？他们最好是:
一旦它们合并到主干中,主干可能会适当增加？
标签似乎从版本号中受益最多.
话虽如此,您如何将您的项目版本(无论是主干,分支,标签等)与SVN相关联？即,作为开发人员,您如何知道1.1.1具有管理员添加统计信息,以及用户添加统计功能？这些描述和链接如何？标签在每个标签中都有发行说明是有意义的,因为它们是不可变的.
但是,是的,你的SVN政策是什么？
我使用trunk,tags,branches模型.
树干:应该始终保持稳定的形式.(不一定是可释放但稳定的,因为没有编译器错误)我通常会进行微小的更改和新功能,这些功能很小,可以在不到一天的时间内完成.如果我要开发需要几天的时间并且签到会使主干处于不稳定状态,我将创建一个分支.
分支: 用于功能开发,可能使主干处于不稳定状态.它还用于"测试"新功能和想法.我确保做一个trunk来分支更新合并,以保持trunk中的最新开发与我的分支同步.
标签:用于我希望快速返回的代码的发行版或稳定版本.通常,我将这些用于模块或应用程序的特定版本(1.00).我尽量不对标签进行任何签到.如果有错误,那么这些更改将在trunk中进行,并将在下一个版本中进行.我做的唯一例外是紧急错误.这意味着标签已经正确QA并且非常稳定.
我在存储库根目录下有trunk、Branches、Tags和工作区。
一切都在一个存储库中，每小时/每天等。备份。为了方便和稳定性，所有步骤（如分支、标签、合并和构建）都已编写脚本（脚本检查存储库一致性）。
仅第二级目录允许分支/合并，并且仅允许完整合并，而不是单个文件/目录（例如分支/LDN_FSHCHPS_REL_2010 --> 工作区/WS_345），以启用自动合并并避免子树合并信息出现问题（并且还可以缓解合并问题发生时的根本原因）
| 归档时间： |
|
| 查看次数： |
20869 次 |
| 最近记录： |