Apache Subversion 存储库是否适合促进多个 .docx、.doc、.xls(s) 等文件的协作编辑？

Question

对于一个为期半学期的项目，一个由五人或更少的人组成的小组将共同完成一个项目，该项目已分发给他们（并且必须转换为 .doc(x)、.xls(x) 等文件的文件夹）。一个特定的文件将看到大部分编辑 --- 一个 .xlsx 文件。

成员将使用 TortoiseSVN 提交更改/进行签出。在这种情况下，SVN 将如何促进协作编辑？——例如，svn 将如何处理由两个不同客户端以不同方式编辑的同一文件的合并？

Answer 1

在这种情况下，SVN 将如何更好地促进协作编辑？例如，svn 如何处理由两个不同客户端以不同方式编辑的同一文件的合并？

这确实是一个双面的问题。

svn 如何处理以不同方式编辑的同一文件的合并

非常好。这确实是任何基于合并的 SCM 的基本功能之一 - 结合不同的变更历史

在这种情况下，SVN 将如何更好地促进协作编辑？

不好的是，正如前面提到的，旧的 MS-Office 文件对于 Subversion 来说“只是二进制文件”，二进制文件的自动合并可能会产生不可预测的结果，对于手动合并，Subversion 管理员需要回答更多的问题，他们可以（必须）为存储库中的 *​​.doc 提供和配置特殊的 diff|merge 工具，以允许最终用户以通常的所见即所得方式进行合并

对于新的基于 XML 的 Office 来说，情况甚至变得更糟。据我所知，閱讀|.xlsx 文件实际上是多文件 zip 存档，理论上合并可以影响和更改多个文件。我不知道如何处理这种情况

Answer 2

SVN 并不真正适合二进制文件（.doc 和 .xls 就是）的版本控制，因为这些文件不包含文本，因此几乎不可能对文件进行差异比较或合并更改。较新的格式（.docx 和 .xlsx）实际上是 XML 文档，它们可以稍微帮助进行差异比较和合并操作，但仍然相当困难。

我的建议是使用类似谷歌文档允许最多 50 位用户进行版本控制和同时编辑（电子表格也是如此）。如果你坚持使用 SVN，我建议你坚持使用纯文本文档，我知道有几个人使用乳胶并使用 SVN 进行一些作业，这使得他们能够进行格式化。

Answer 3

不多。事实上，没有哪个版本控制系统擅长这样的任务，它们专门处理纯文本文件（您提到的类型都是二进制文件）。您可以处理它们，但像“显示更改”或“谁做了...”这样的任务不会有答案。这就是版本控制的大部分要点。

也许更好的解决方案是通过 Google Docs 或类似方式共享文档？