前面的文章 说到。ClearQuest附件可以放在第三方存储了。然后Attachments 2.0 Packages证明只能连到FTP。
还是想放在ClearCase上面。其实就是还想实现版本控制的问题。
最好的场景是:
CQ上传附件开始,就进行版本控制,用户进行删除、添加时就是对版本控制下的文件进行CO,CI的操作。
老规矩第一步还是马上收集资料
不过这个就想yunshan本人说的。这个上传到FTP上,其实就是相当于一个备份 ,而CQ每次读取仍然是本地的数据。
2:Storing ClearQuest attachments in an FTP area
发现迁移后,记录的附件没了 ,也没有了关联,这样以后查历史都不好查啊。
限制附件大小
AttachmentFields is a collection object similar to the standard Visual Basic collection objects.
其实上面做的就是类似Attachments 2.0做的事情。CQ上传附件,然后把附件上传到第三方存储比如FTP等,然后生成一个可以直接访问文件的URL。
其实为了避免CQ数据库过大。对于附件的处理无非下面三种:
1:限制上传附件大小。(资料里面的3)
2:定时迁移历史附件(资料里面的2)
3:上传附件到第三方存储。(资料里面的1,Attachments 2.0等)
我们重点关注的是3:上传附件到第三方存储。
想当然第三方存储无非就是FTP或者共享文件夹,然后CQ这边加个URL,以后附件都通过URL访问(其他的目前没接触到。也想不到)。
CQ这边实现上传附件到FTP还是共享文件夹技术算是有的。应该算成熟。(实在不行。直接用Attachments 2.0)
接着就是CC怎么平滑处理这些第三方存储上面的文件和文件夹
文件或者目录添加到源控制,CC就可以开始版本控制了。(到这算是完事了。哈哈。)
其中会遇到的一些问题:
1:CQ的附件是上传的同时就直接发到第三方存储(Attachments 2.0给人的印象就这么干,具体不清楚),还是先保存在CQ数据库再发到第三方存储。然后再删除CQ数据库里面的东西。还有上传的速度如何。
2:访问第三方存储的URL,对中文支持好不好。(按照常理应该没问题)
3:CQ附件同名处理问题。用户早上上传了一个Av.txt,然后下午再上传个Av.txt。(可以通过上传文件同时,给文件加上时间做标识。URL显示的是最后一个文件生成的URL)
4:CQ附件多个的问题。生成多个URL一定不友好(限制只能上传一个附件。让用户把多个文件打成一个包上传。或者URL直接给的是文件夹。同一个记录上传的附件都在同一个文件夹下面。这个也可以参考Attachments 2.0的做法。待研究)
5:CC这边怎么把这么多CQ附件添加源控制。(可以脚本一天执行一次。或者检测到有新文件就添加一次)
6:CC这边怎么下一步的版本控制。(未知。待考虑)
update:2010-7-30下午
CQ把附件添加到CC共享文件夹比如M盘的一个文件夹。然后自动运行一个cmd执行cleartool。添加到vob中的方案是可行的。
这个主要应用于:CQ中的附件自动归档到CC
可以解决这样的场景:
当CQ达到某个状态(或closed)时,自动触发脚本将附件添加到CC指定位置进行版本控制
要解决完美场景
CQ上传附件开始,就进行版本控制,用户进行删除、添加时就是对版本控制下的文件进行CO,CI的操作。
除非谁真的花大精力去写一个CQ调用CC api进行添加源控制,检入。检出的触发控制~相信难度相当大~并且吃力不讨好。