序言
前段时间参予的工程建设项目标识符代销是用github，用下来觉得和我平常采用的svn还是很多不同的，一直在构想和探索PLM工程建设项目中采用版管理工作远距工具来管理工作标识符的合作开发业务流程，趁此机会明晰归纳一下。
难题
PLM工程建设项目在实行过程中，合作开发项目组经常被非议为家庭式，没合作开发业务流程，没标识符版管理工作，或者有标识符管理工作而仅用作存档。
这是由于PLM工程建设项目物理性质决定的，合作开发占比较为少，远距为主，且多为二次合作开发，机能相对较为分立，我参予过的的工程建设项目有一个合作开发技师，兼工程建设部门经理、业务高级顾问、实行的小工程建设项目，也有十多个合作开发的大工程建设项目，在绝大多数工程建设项目实用性中，合作开发也就两三个且还不一定在当晚，所以合作开发操作过程中也不是亟需标识符管理工作及合作开发业务流程规范化，常常是在中后期工程建设项目上线及网络管理工作升级换代这时候，才折射出未对标识符版管理工作及合作开发业务流程规范化的弊病，比如说如下表所示这些情况：
1.标识符武装冲突
王承恩博戈达合作开发合包这时候库文档版、远距工具类等武装冲突。
2.标识符输入输出
各别保护的工程建设及远距工具类，到最后合包这时候远距工具类中很多多次重复相近的方法，但已经到中后期，不太愿精心安排附加的时间去做标识符解构资源整合再次试验了。
3.版不太好回溯
比如说标识符回调，如果未做标识符力学存储及更改历史记录，将变的很十分困难，历经过的很多顾客，标识符根本无法在企业内部网撰写，且内部网并没版管理工作远距工具，标识符在合作开发和网络管理工作这时候，我为了防止标识符版出现难题，对合作开发项目组采用了标识符力学存储的合作开发业务流程规范化，修正标识符前先对新一代标识符做一次存储，在历史记录文档中历史记录签出签入的人、时间、原因及改动的标识符文档清单，为了防止出现难题，大家都尽量防止对未签入的标识符做再次签出修正，好在平常协同合作开发网络管理工作的场景较为少，项目组也严格遵守这个业务流程，未出现过标识符版难题。
4.生产环境和标识符不匹配
因为没合作开发业务流程，随着上架后的网络管理工作及人员流动交接，最后的结果常常就是新一代标识符和生产环境的部署包匹配不上，java标识符还可以通过反编译出生产标识符来和当前新一代标识符对对比，c标识符就较为十分困难了，根本无法通过梳理机能再次合作开发来恢复代码，给网络管理工作及升级换代带来附加工作量和风险。
5.标识符丢失风险
如果没很好的标识符本地及异地存储机制，可能会出现辛苦写的标识符不小心丢失了的情况，历经过磁盘或者虚拟机坏掉的同学一定感同身受。
解决
平常我们实行工程建设项目时候需要帮顾客梳理业务业务流程，然后在PLM软件上面落地，其实我们合作开发项目组也需要根据情况梳理出一个合作开发业务流程，然后在svn或者git这些版控制软件上落地。
我的项目组采用的是学习成本较为低的svn，从采用svn的4年期间，总共在svn上管理工作了26家顾客的37个大大小小的工程建设项目标识符，不断归纳实践，归纳了基于svn的PLM工程建设项目特色合作开发业务流程(svn中相关概念可以参照“关于svn”章节)。我们采用的合作开发业务流程和规则(图1，后面“工程建设项目案例”章节将结合该合作开发业务流程介绍我在上汽大通工程建设项目PLM工程建设项目合作开发及网络管理工作操作过程中实战案例)：
1.trunk：主干，用作保护和生产环境一致的标识符
2.branches：分支，每个工程建设项目合作开发这时候对应一个分支
3.tags：标签，快照，每个工程建设项目最后上架部署后，标识符(分支基于主干合并后的标识符)对应一个tags
4.工程建设项目及日常bug修复合作开发业务流程如下表所示:
4.1.合作开发经理基于当前trunk创建branches
4.2.给branches分配合作开发技师和权限，并通知合作开发技师
4.3.合作开发技师将branches签出到本地进行合作开发
4.4.合作开发技师定期同步branches中标识符到本地(一般每天工作开始这时候)，定期提交标识符到branches(标识符到一定成熟度这时候，建议每天下班这时候)
4.5.合作开发经理定期同步trunk中新一代标识符到branches中(一般是有其它工程建设项目上架或者网络管理工作修复bug上架后)
4.6.机能试验这时候基于branches标识符编译发布
4.7.最后机能上架时，合作开发经理\合作开发技师合并branches标识符到trunk，并编译快速试验，发布tag
5.紧急修复合作开发业务流程如下表所示：
其它步骤和工程建设项目和常规修复bug一样，区别在，不需要创建branches，直接签出trunk到本地修复bug试验通过后直接提交到trunk发布
图1：PLM工程建设项目基于svn的合作开发业务流程
关于svn
svn有一个很标准的目录结构，是这样的。比如说工程建设项目是proj，svn地址为svn://proj/，那么标准的svn布局是 ：
图2：标注svn的目录结构
这是一个标准的布局，trunk为主合作开发目录，branches为分支合作开发目录，tags为tag存档目录（不允许修正）。但是具体这几个目录应该如何采用，svn并没明确的规范化，更多的还是用户自己的习惯。
svn各个目录含义
trunk：主干，如果说把一个软件工程建设项目从开始到消亡比作一个故事的话，主线情节都在这里被svn历史记录着。
branches：分支，有很多种用法，比如说：版发布保护分支、新特性合作开发分支，甚至是缺陷修复分支等等。
tags：标签，或者叫快照，某个版发布这时候，都在这里留档。
示例如图：
图3：标准svn目录结构
采用svn合作开发业务流程可以分成集中式和分散式两种：
集中式：trunk进行主要合作开发
一般的，我们的所有的合作开发都是基于trunk进行合作开发，当一个版/release合作开发告一段落（合作开发、试验、文档、制作安装程序、打包等）结束后，标识符处于冻结状态（人为规定，可以通过hook来进行管理工作）。此时应该基于当前冻结的标识符库，打tag。当下一个版/阶段的合作开发任务开始，继续在trunk进行合作开发。
此时，如果发现了上一个已发行版（Released Version）有一些bug，或者一些很急迫的机能要求，而正在合作开发的版（Developing Version）无法满足时间要求，这这时候就需要在上一个版上进行修正了。应该基于发行版对应的tag，做相应的分支（branch）进行合作开发。
这是一种很标准的合作开发模式，很多的公司都是采用这种模式进行合作开发的。trunk永远是合作开发的主要目录。
分散式：分支进行主要合作开发
这种合作开发模式当中，trunk是不承担具体合作开发任务的，主要承担版发布，一个版/阶段的合作开发任务在开始的这时候，根据已经release的版做新的合作开发分支，并且基于这个分支进行合作开发。
这其实是一种分散式的合作开发，当各个部分相对分立一些（机能性的），可以开多个dev的分支进行合作开发，这样各人/组都不会相互影响。比如说dev_2.0_search和dev_2.0_cache等。但是这样merge起来就是一个很痛苦的事情。
所以，合包这时候选择性的merge，是可以当2.0合作开发结束后一起把dev_1.0（bugfix用）和dev_2.0（新版合作开发用）merge回trunk。或者先把dev_1.0 merge到dev_2.0，进行试验等之后再merge回trunk。
这两种方法各有利弊，第一种方法是可以得到一个较为纯的合作开发分支，而第二种方法则更加的保险，因为要试验嘛。
王承恩协作时，合包是最经常出难题的地方，严重的甚至会导致标识符被覆盖回滚情况，其原因在于分支管理工作者创建分支后不再或长时间从主干拉回数据，导致最后合并回主干时分支的文档甚至结构都与主干有较大差别，产生较多武装冲突。需要人手解决，浪费了很多时间。
针对这个难题，是否有一种方案可以在分支提交时即检测该分支最后一次合并的版是否与主干版相符，如果不符则不允许提交，强制要求大家养成从主干拉数据的习惯呢？如果可以实现，那么在分支合并回主干时将几乎可以消灭掉武装冲突。
两种方法的优缺点
第一种合作开发模式（trunk进行主要合作开发，集中式）：
优点：管理工作简单。
缺点：当合作开发的模块较为多，合作开发人数/小项目组较为多的这时候，很容易产生武装冲突而影响对方的合作开发。因为所有的改动都有可能触碰对方的改动。
第二种合作开发模式（分支进行主要合作开发，分散式）：
优点：各别合作开发分立，不容易相互影响。
缺点：管理工作复杂，合包merge的这时候很麻烦，容易死人。
工程建设项目案例
下面我将结合一个较为复杂的工程建设项目场景介绍下合作开发业务流程的实战，该案例跨度有一年左右，加上日常系统网络管理工作，算是同一个顾客的7个工程建设项目博戈达合作开发，我身为合作开发经理，借用上面归纳的PLM工程建设项目中的合作开发业务流程防止了很多坑。
首先介绍下案例情况，顾客是上汽大通，工程建设项目主干线是从Teamcenter8.3升级换代到Teamcenter11.3，升级换代操作过程中博戈达了6个工程建设项目合作开发，总共投入了9个合作开发技师，角色和工程建设项目情况如图4，从表中可以看出来有5个是多个合作开发协同工程建设项目，且有4个由于部分合作开发不采用svn导致标识符不能全部用svn管理工作，会多出附加的标识符比对合并工作量。
图4:合作开发、角色、是否采用版管理工作远距工具及工程建设项目矩阵表
该案例我采用的合作开发业务流程如下表所示，主要加入了不使用svn合作开发的标识符处理：
1.trunk：主干，用作保护和生产环境一致的标识符
2.branches：分支，每个工程建设项目合作开发这时候对应一个分支
3.tags：标签，快照，每个工程建设项目最后上架部署后，标识符(分支基于主干合并后的标识符)对应一个tags
4.工程建设项目及日常bug修复合作开发业务流程如下表所示:
4.1.合作开发经理基于当前trunk创建branches
4.2.给branches分配合作开发技师和权限，并通知合作开发技师
4.3合作开发技师将branches签出到本地进行合作开发
4.4.对于不采用svn的合作开发，需要合作开发经理下载新一代标识符后，离线发送
4.5.合作开发技师定期同步branches中标识符到本地(一般每天工作开始这时候)，定期提交标识符到branches(标识符到一定成熟度这时候，建议每天下班这时候)
4.6.对于不采用svn的合作开发，需要合作开发经理定期接收标识符和trunk标识符做线下对比，并和合作开发确定修正内容后合并到trunk
4.7.合作开发经理定期同步trunk中新一代标识符到branches中(一般是有其它工程建设项目上架或者网络管理工作修复bug上架后)
4.8.机能试验这时候基于branches标识符编译发布
4.9.最后机能上架时，合作开发经理\合作开发技师合并branches标识符到trunk，并编译快速试验，发布tag
5.紧急修复合作开发业务流程如下表所示：
其它步骤和工程建设项目和常规修复bug一样，区别在，不需要创建branches，直接签出trunk到本地修复bug试验通过后直接提交到trunk发布。
这套合作开发业务流程采用下来，虽然合作开发经理每次合包merge这时候都要对比标识符很是麻烦，但好在稳当可靠没出现重大的标识符版错误，还通过日常review标识符这时候防止了一次事故(不采用svn标识符的合作开发后来开始采用svn，提交标识符前未从trunk同步新一代标识符，导致将本地老标识符提交到了trunk中)，我在日常review标识符这时候及时发现了做了标识符回调。
归纳
整体上采用版管理工作PLM工程建设项目标识符，优点多于缺点，如果你的合作开发项目组没采用，强烈建议采用。
