![Apache Subversion 存储库是否适合促进多个 .docx、.doc、.xls(s) 等文件的协作编辑?](https://linux22.com/image/1353750/Apache%20Subversion%20%E5%AD%98%E5%82%A8%E5%BA%93%E6%98%AF%E5%90%A6%E9%80%82%E5%90%88%E4%BF%83%E8%BF%9B%E5%A4%9A%E4%B8%AA%20.docx%E3%80%81.doc%E3%80%81.xls(s)%20%E7%AD%89%E6%96%87%E4%BB%B6%E7%9A%84%E5%8D%8F%E4%BD%9C%E7%BC%96%E8%BE%91%EF%BC%9F.png)
对于一个为期半学期的项目,一个由五人或更少的人组成的小组将共同完成一个项目,该项目已分发给他们(并且必须转换为 .doc(x)、.xls(x) 等文件的文件夹)。一个特定的文件将看到大部分编辑 --- 一个 .xlsx 文件。
成员将使用 TortoiseSVN 提交更改/进行签出。在这种情况下,SVN 将如何促进协作编辑?——例如,svn 将如何处理由两个不同客户端以不同方式编辑的同一文件的合并?
答案1
在这种情况下,SVN 将如何更好地促进协作编辑?例如,svn 如何处理由两个不同客户端以不同方式编辑的同一文件的合并?
这确实是一个双面的问题。
svn 如何处理以不同方式编辑的同一文件的合并
非常好。这确实是任何基于合并的 SCM 的基本功能之一 - 结合不同的变更历史
在这种情况下,SVN 将如何更好地促进协作编辑?
不好的是,正如前面提到的,旧的 MS-Office 文件对于 Subversion 来说“只是二进制文件”,二进制文件的自动合并可能会产生不可预测的结果,对于手动合并,Subversion 管理员需要回答更多的问题,他们可以(必须)为存储库中的 *.doc 提供和配置特殊的 diff|merge 工具,以允许最终用户以通常的所见即所得方式进行合并
对于新的基于 XML 的 Office 来说,情况甚至变得更糟。据我所知,閱讀|.xlsx 文件实际上是多文件 zip 存档,理论上合并可以影响和更改多个文件。我不知道如何处理这种情况
答案2
答案3
不多。事实上,没有哪个版本控制系统擅长这样的任务,它们专门处理纯文本文件(您提到的类型都是二进制文件)。您可以处理它们,但像“显示更改”或“谁做了...”这样的任务不会有答案。这就是版本控制的大部分要点。
也许更好的解决方案是通过 Google Docs 或类似方式共享文档?