问题/环境描述
我们目前有大约 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 等，如果人们意外地保存到共享，将导致许多副本。
到目前为止，我有一个模糊的想法，我可以编写一些脚本来处理复制到共享的可写“drop box”，例如...拒绝 zip 文件，并拒绝覆盖任何文件。这需要我手动删除任何文件（有时是必要的，但很少见 - 或者可以交给一组选定的用户）。也许尽管 Subversion 不完美，但它并不糟糕...我在这里寻求一些其他的意见。我不想改变每个人的工作流程，只是为了让我或用户（30-40 个用户）的工作变得更加繁重。
答案1
我应该等待你对我的评论的回复，但是......
怎么样：
您的文件的只读共享。
具有相同目录结构的可写共享。
当有人需要更新文件时，他们会从只读共享中“签出” - 即在本地复制一份。（我接下来要说的局限性在于不是退房流程...)
他们在本地处理文件，任何临时文件都只在他们的硬盘上。
当他们完成文件更新后，他们会将其复制回可写共享上的正确目录。
使用众多文件复制工具（rsync、SecondCopy 等）中的一种，按照您想要的时间间隔，将文件从可写目录复制到相应的只读目录。文件的新版本将覆盖前一个版本，或者您可以根据需要保留当时的版本。
正如我所说，该系统没有实际的签出，它不处理两个或多个人同时处理同一个文件的情况。我猜冲突解决可以利用这样一个事实：人们会有一个本地副本（至少在一段时间内）作为后备。
答案2
我不明白为什么你使用版本控制系统，而你显然没有使用它。现在你没有获得版本控制的好处，但仍在使用资源方面付出代价。
根据您的描述，我建议改用传统的文件/文件夹共享。为什么要让它变得比需要的更复杂呢？使用清晰合理的文件夹命名和分层最容易建立结构。我相信您的用户不仅会很快适应它，而且会感谢您的改变。