Polarion用代码的方式管理需求和测试文档

本文简要说明，第一章文章背景，第二章SVN代码管理方式，第三章Polarion文档管理方式，结尾留了一个彩蛋。

背景说明

同事近来反馈Polarion系统中的文档提交文档审批之后，无法编辑，他们需要一个可以持续编辑的文档空间，要在文档审批窗口期继续干活。当听到这个需求的时候，我当时想的文档审批不就应该锁定吗？文档评审有问题，打回来重新改，再次提起流程，就好了呀？

但是同事说了，如果不使用Polarion系统，而是使用Word工作，签批的文档另存为一个文档发出审批，他们依然可以在原来的那份文档继续编辑，继续干活，他们不会等审批结果再编辑。

那么，同事的电脑里有一份可以编辑的文档，另有几份外发只读的文档。

以上是我们线下工作场景，而切换到Polarion之后，一个项目作者要编辑内容的文档只有一份，我们禁止相同的文档内容多份，这样会导致数据重复，上下游覆盖率无法统计。文档发起审批流程后文档被冻结。因为不冻结的话，不同评审人，批准人看到的版本不一样；另外，文档签字也会出现问题。审批中，作者更新了文档内容，会让发出去的签字版本成为历史版本，签批人通过点击链接到文档中打开的是历史版本，无法签批，需要返回当前版本才能签批。

以上就是我们之前使用过Polarion系统中遇到的困境，那么如何在内容不重复的情况下，既让作者有一个可以持续编辑的空间，又要保证签批的版本是只读不变的呢？

SVN代码管理方式

在介绍Polarion中的功能之前，我们先看一下SVN常用的代码主干和分支的管理方式，之所以用SVN而不是Git，因为Polarion系统是使用SVN存储文档。

在SVN中管理代码主干和分支基本是按照上面的方式进行：

1. Trun