有时候，代码明明已经提交到SVN上面了，可在对应的需求页面里却完全找不到这次修改的记录，等到了版本审查的时候，就很难把某一条需求到底改过哪些文件给说清楚。要想搞明白Polarion怎么去关联SVN的提交，以及当提交记录在需求那边追溯不到时又该怎么处理，最核心的两件事，就是先把外部的SVN仓库接到Polarion里来，再让开发人员在每次提交时，都把正确的Work Item ID填在备注信息里面。Polarion本身是支持把外部Subversion仓库里的代码变更，跟相应的Work Item挂上钩的，这样一来，需求、任务和代码改动之间，就能形成一条可以往回追溯的链路。

　　一、Polarion怎么关联SVN提交

　　要想让SVN的提交自动关联上，并不需要开发人员每次手动打开Polarion去补记录。只要管理员事先把仓库配置好，开发人员按照统一的格式去写提交备注，系统自己就能认出对应的Work Item。

　　1、先把外部的SVN仓库配好

　　进到项目管理的相关区域，找到外部仓库（External Repositories）的设置项，把SVN仓库的地址给新加上去，同时填好有权限访问的账号和密码。按照Siemens的官方资料，外部SVN仓库在项目管理的页面上就可以完成配置，而且Polarion会一直去监控这个仓库的变动。

　　2、在提交备注里带上Work Item ID

　　开发人员每次提交代码的时候，只要在SVN的备注信息中，把对应任务或者需求的编号给写进去，比如PROJ-123，Polarion一旦识别到这个编号，就会自动把这一次的SVN revision关联到那个Work Item下面。Siemens官方的文章也明确说过，开发人员可以用任意一种SVN客户端去提交，唯一的条件就是要在备注里填上Work Item ID，这样关联就能自动建立起来。

　　3、提交完了之后检查关联结果

　　打开对应的那个Work Item，在关联的Revisions或者跟代码变更相关的区域里看一看，确认SVN的revision编号、提交人、提交时间，还有修改过的那些文件，都已经显示出来了。如果同一次提交里涉及了好几个Work Item，也可以在备注里把多个编号一块儿写上去，但要注意别把那些不相干的需求也顺手带了进去。

　　4、统一团队里写备注的格式

　　建议团队内部固定出一种格式来，比如在前面放上编号，后面跟上说明文字，像是“PROJ-123修复登录超时判断”。千万不要只笼统地写上“修改代码”或者“问题修复”这类看不清楚目的的内容，要不然以后就算找到了那条提交记录，也不太容易看明白当初到底是为了什么才改的。

　　二、提交记录追溯不到需求的时候怎么办

　　提交明明已经完成了，可需求页面底下却没冒出对应的revision，这时候先别急着把同一份代码再交一次。很多时候，问题其实是出在了编号、仓库配置，或者追溯的层次关系没有处理完整上面。

　　1、先检查Work Item ID是不是写错了

　　仔仔细细地核对一下项目的缩写、数字的编号、大小写，还有中间的连接符。只要Work Item ID写错了一位，Polarion就没法自动把它认出来，另外还要确认这个编号确实是属于当前Polarion项目的，别把其他项目里的任务编号给误写了进来。

　　2、检查SVN仓库是不是挂对了地方

　　得确认一下这次提交，确实是在那个已经配置好的仓库、分支和目录底下发生的。假如代码后来迁移到了一个新的SVN地址上，而Polarion那边却还在监控着旧的仓库地址，那页面里自然看不到新的revision，同时也要检查一下仓库的账号有没有失效，服务端还能不能正常读到提交的历史。

　　3、漏掉了编号就用手工的方式补上关联

　　代码是已经提交上去了，但备注里当初忘记写Work Item ID，这时千万别为了补一段备注，再去人为制造一次毫无意义的提交。比较直接的办法，是打开对应的那个Work Item，在Linked Revisions区域里，手工把revision的编号填进去。Siemens官方的文章里也提到了，开发人员完全可以回到Work Item里，直接填写SVN revision来完成这种补充的关联。

　　4、检查需求和开发任务之间到底有没有串起来

　　很多时候，代码提交是先跟开发任务关联在一起的，而不是直接连到上层的需求。如果这条任务没有继续向上链接到需求，那么即便代码记录已经存在，在需求页面那里也仍然看不到一条完整的追溯链。在实际操作里，应该要尽量保持“需求—开发任务—SVN revision”这种关系是清晰的，而Polarion本身也是支持从修改的代码一路追溯回到最顶上的变更请求的。

　　三、Polarion SVN追溯链路怎么维护

　　等提交关联这套机制能顺利跑通之后，还得把执行的规则给它固化下来。不然随着团队里面的人越来越多，漏填编号的、写错编号的，还有跨分支混用的情况，就会变得越来越常见。

　　1、把填写编号这个动作嵌入到开发流程里面

　　当需求或者缺陷流转到开发阶段以后，最好是先去创建对应的开发任务，然后把Work Item ID，放到分支名称里、提交的备注里，还有合并的说明当中去，这样代码、任务和需求这三者之间对齐起来，就会容易得多。

　　2、按照版本去抽查那些没有关联上的提交

　　每次在正式发布之前，可以把当前版本用到的SVN revision做一次抽查，重点去翻看那些没有带Work Item编号的提交，一次关联了过多任务的提交，还有修改的范围明显跟需求内容对不上的提交。

　　3、保留手工补做关联的记录

　　在漏填编号之后，如果采取了手工补充revision的方式，就应该同时在那条Work Item的评论里面，把漏掉的原因给写清楚。往后在复盘的时候，就能够更方便地判断出来，这到底是个人操作上一时疏忽，还是仓库配置、同步任务或者访问权限出了什么问题。

　　总结

　　所以，Polarion怎么去关联SVN提交，比较普遍的做法就是先在项目管理的区域里，把外部的SVN仓库接进来，然后再要求开发人员在提交的备注中，把正确的Work Item ID给填进去。当遇到提交记录追溯不到需求的情况时，优先要排查编号的格式、仓库的地址、访问的权限，以及需求到任务这一层链接关系有没有断开。只要能把提交备注的规范、手工补关联的记录，还有版本发布前的内部抽查，这几样工作都保留下来形成习惯，代码的追溯链路就会变得清晰很多，后面再碰到审核，也不至于半天找不到依据。