我们目前有大约100 GB的CAD文件(90k文件,6k目录)存储在几个Subversion存储库中.在Subversion中保留这么多二进制数据似乎是一种不必要的麻烦/负担.这也是人们检查新文件的负担,因为他们需要添加&在他们可以提交之前签出一个目录.能够恰到好处地点击并“更新”的唯一“优势”是每个文件的2个副本被存储(svn如何工作),并且非常慢.文件没有有意义的版本历史记录 – 即CAD文件不会被添加进一步修改,或者如果是这样,在这种特殊情况下,它不是我们关心的数据 – 只有当前,最新状态或HEAD.从SVN导出数据非常简单.编辑文件并不是工作流程的一部分,更可能是偶然的,它涉及5个CAD系统,所以我不确定“PLM”类型的系统是否真的是理想的或有保证的.
文件服务器的当前环境是Windows Server 2003 – 可能会在6个月内更改(无论是服务器2008 R2大RAID 6,还是NAS,可能是服务器2008 R2,无论哪种方式)
由于庞大的规模,没有人经常检查所有部分(甚至是给定目录),并且已经有一个只读网络共享,每天从Subversion更新一次.自动更新过程一直打破(svn工作副本变脏或处于错误状态并需要清理).这就是大多数用户访问这些部分的方式,因此他们已经习惯于从共享中访问,这主要是对部分添加方式的改变.
有哪些新的工作流程选项？我错过了什么吗？
我想更新处理CAD文件的工作流程.表中考虑的当前情况是直接的Windows网络共享.理想情况下保持这种只读行为,但显然人们需要一个地方来转储新文件并将它们添加到共享中.如果网络共享成为数据的主要来源,那么人们不会一直打开,编辑和保存文件是很重要的.我认为这一点的重要性值得商榷,但通常如果编辑,合同是将它们复制到PC中,因此不会为其他人修改给定文件的“主”副本.
试图将添加文件与访问文件分开是不是值得麻烦？ (保持对该共享的只读访问权限)
设置要写入但不能修改的共享不一定是一个选项(如果保持只读是核心要求),就像Pro / ENGINEER等CAD系统获取CAD文件XYZ.prt一样,每个保存增量都是一个数字……例如. XYZ.prt.1,XYZ.prt.2等,如果人们意外保存到共享,将导致许多副本.
到目前为止,我有一个朦胧的想法,我可以编写一些东西来处理一个可写的“下拉框”,复制到共享,例如…拒绝zip文件,并拒绝覆盖任何文件.这使我有了删除任何文件的手工任务(偶尔必要,但很少 – 或者可以给予选定的一组用户).也许尽管它的不完美Subversion并不可怕……我在这里寻找其他一些意见.我不想要的只是改变每个人的工作流程,以使情况更适合我或用户(30-40个用户).
怎么样：
>文件的只读共享.
>具有相同目录结构的可写共享.
>当有人需要更新文件时,他们会从只读共享中“检出” – 也就是说,他们会在本地复制它. (接下来我要说的是,没有退房流程……)
>他们在本地处理文件,任何临时文件只在他们的硬盘上.
>完成更新文件后,会将其复制回可写共享上的正确目录.
>使用众多文件复制工具之一(rsync,SecondCopy,无论如何),无论您想要什么时间间隔,文件都会从可写目录复制到相应的只读目录.该文件的新版本将覆盖前一版本,或者如果您愿意,可以保留该版本的版本.
正如我所说,在这个系统中没有实际的签出,它不会同时处理两个或多个同一个文件的人.我想碰撞解决方案可以利用这样一个事实,即人们会将他们工作的本地副本(至少在一段时间内)重新开始.
