我们目前有大约100 GB的CAD文件（90k文件，6k目录）存储在几个Subversion版本库中。 在Subversion中保留这么多的二进制数据似乎是一个不必要的麻烦/负担。 这也是人们检查新文件的负担，因为他们需要添加和签出目录才能提交。 唯一的“优点”是能够右键单击和“更新”，每个文件被存储2个副本（svn如何工作），速度非常慢。 文件没有有意义的版本历史 – 也就是说，CAD文件不会被进一步修改，如果是这样，在这种情况下，它不是我们关心的数据 – 只有当前的最新状态或HEAD。 ..从SVN导出数据很简单。 编辑文件不是真正的工作stream程的一部分，更可能是偶然的，它涉及5个以上的CAD系统，所以我不确定“PLM”types的系统是否真的是理想的或有保证的。
文件服务器的当前环境是Windows Server 2003 – 这可能会在6个月的时间内发生变化（无论是服务器2008 R2 +大型RAID 6，还是NAS，可能都是服务器2008 R2）
由于规模庞大，没有人真正检查出所有的部分（甚至是给定的目录），而且已经有一个只读的networking共享，每天从Subversion进行一次更新。 自动更新过程总是中断（svn工作副本变脏或处于不良状态，需要清理）。 这就是大多数用户如何访问这些部分，所以他们已经相当习惯从共享中进行访问，这主要是对如何添加部分的一个改变。
我想更新我们的工作stream程来处理CAD文件。 目前的桌面考虑是直接的Windowsnetworking共享。 理想情况下保持这种只读行为，但显然人们需要一个地方来转储新文件，并将其添加到共享。 如果networking共享成为数据的主要来源，那么重要的是人们不要一直打开，编辑和保存文件。 我认为这个问题的重要性是值得商榷的，但是一般来说，如果要进行编辑，合同是把它们复制到自己的PC上，这样给定文件的“主要”副本就不会被其他人修改。
试图分开添加文件访问它们是不值得的麻烦？ （保持共享的只读访问）
设置共享写入但不能修改不一定是一个选项（如果保持只读是一个核心要求），就像Pro / ENGINEER的CAD系统拿到CAD文件XYZ.prt，并且每个保存增量一个数字… Eg 。 XYZ.prt.1，XYZ.prt.2等，如果人们不小心保存到共享中，会导致很多副本。
到目前为止，我有一个朦胧的想法，我可以编写脚本来处理一个复制到共享的可写“下拉框”，例如…拒绝zip文件，并拒绝覆盖任何文件。 这给我留下了删除任何文件的手工任务（有时是必要的，但很less见 – 或者可以给予一组选定的用户）。 也许尽pipe它的不完美Subversion是不可怕的…我在这里寻找一些其他的意见。 我不想要的是仅仅改变每个人的工作stream程，以使我或用户（30-40个用户）更适合这种情况。
我应该等待你对我的评论的回应，但是…
怎么样：
您的文件的只读共享。
具有相同目录结构的可写共享。
当有人需要更新文件时，他们从只读共享中“检出” – 也就是在本地复制一份文件。 （接下来我要说的限制是没有退房过程…）
他们在本地文件上工作，任何临时文件只在他们的硬盘上。
当他们完成更新文件时，他们将其复制回可写入共享上的正确目录。
使用许多文件复制工具（rsync，SecondCopy，无论）中的一个，以任意间隔，将文件从可写目录复制到相应的只读目录。 新版本的文件将覆盖前一个版本，或者如果您愿意，可以保留版本。
正如我所说，在这个系统中没有实际的检查，它不处理同时在同一个文件上工作的两个或两个以上的人。 我想这个碰撞解决scheme可以利用这样一个事实，那就是人们可以在本地复制他们的工作（至less在一段时间内）。
我不明白为什么你使用版本控制系统，当你明显不使用它。 现在你没有得到版本控制的好处，但仍然在使用的资源上付出代价。
鉴于你的描述，我build议使用传统的文件/文件夹共享。 为什么要把它变得比所需要的更复杂呢？ 结构是最容易build立使用清晰，明智的文件夹命名和分层。 我相信你的用户不仅会很快适应，而且会感谢你的改变。