据我所知,微软在其最新版本的办公室中使用了某种基于xml的表示法。如果这是真的,那么我会假设版本控制可以工作,虽然你显然必须用旧的
解决任何嵌入式更改<<<<<<
======
>>>>>>
在加载单词之前标记它们。
这个问题提到了这个问题,但似乎认为版本控制根本不适用于Word,我想知道为什么会这样做?
Is version control (ie. Subversion) applicable in document tracking?
答案 0 :(得分:7)
Mercurial有zipdoc extension,它似乎通过在内部存储未压缩的文件来处理基于XML的Word文档等压缩文件,以获得有意义的增量,并以有意义的方式合并它们。我没有测试它,但它听起来像你正在寻找的东西。
答案 1 :(得分:3)
已成定定的结论是,虽然包括Mercurial在内的大多数(如果不是全部)版本控制系统确实可以使用二进制文件,但它们在分析和合并它们时很糟糕。
Word文件本质上是二进制文件。是的,Office的最新版本已经转换为“Office Open XML”格式,其中包括XML,但它们仍然将整个内容包装在一个zip文件中,这意味着它仍然是二进制文件(是的,我知道所有文件都在事实二元,你知道我的意思。)
现在,许多版本控制系统,包括Mercurial和Subversion,都可以通过为它提供可以完成工作的外部合并工具来告诉如何合并它认为是二进制文件的任何文件类型。
这基本上意味着,如果你能找到一个程序可以获取两个Word文件,区分它们,并允许你协调差异,那么你就是在做生意。
如果您解压缩Word文件并对内容进行版本控制,那么是的,您可能会遇到可以通过Mercurial解决的合并冲突,但是内容仍然是您自己没有编写的格式,因此难以协调合并冲突可能并不困难,它们可能是不可能的。
简而言之,版本控制系统在存储二进制文件方面表现出色,但他们会嘲笑 diffing 和合并。
如果您永远不需要差异或合并,您可以使用Mercurial或Subversion或其他任何东西,它会很有效。
答案 2 :(得分:2)
新格式实际上是基于XML的,但.docx文件本身实际上是一个zip文件。所以最终它仍然是一个二进制文件...
答案 3 :(得分:1)
我想这取决于谁将使用这些文件。通常只有开发人员才习惯使用VCS,因此您可能会使那些只想通过共享驱动器访问的人的生活变得复杂。
另一方面,修订历史通常非常重要,我经常会在顶部看到带有大摘要的单词文档,列出所有更改,这看起来非常愚蠢。
我认为谷歌文档等基于云的解决方案可能会在未来填补这一空白。或者只是一个团队维基。一般来说,您正在权衡一些较为高级的单词功能,以获得更开放的分享体验,但谷歌文档正变得非常强大。
答案 4 :(得分:1)
我将Use Case放在前台。世界上有很多人需要工具来比较同一个Word文档的两个版本 - 但他们不是开发人员,而是例如律师。在我的律师事务所客户,文件发送给他们的客户并返回编辑,因此基于文档的比较是绝对必要的。它们使用内置的Word比较功能或第三方工具(WorkShare DeltaView就像是行业标准)。这些工具还允许比较PDF文档。
此处的用例显然是内容驱动的:律师需要快速了解合同的两个版本之间的差异。两个版本都可以作为“版本”存储在文档管理系统中,或者在DeltaView的情况下,可以存储增量文件以供进一步查看。
开发人员的用例是什么?源控制系统意味着“SOURCE”控制,而不是“控制我项目中出现的所有内容”。我宁愿将项目相关文档(计划,规格,要求,电子邮件)存储在另一个商店中,而不是存储在Mercurial中。 - 另一方面,我经常在文档模板项目中使用 Word文档或Word模板作为解决方案的一部分,当然这些文档也是源文件 - 因此保存在repo中。但是可视化差异的需求到目前为止相对较小,特别是如果您的评论很好(“版本1 - 初始化”,“版本2:在标题中添加了文本框”,“版本3:添加了页脚”信息“等。)。
答案 5 :(得分:1)
这里回答各种观点或假设:
如果您想要关键字扩展,请考虑使用XML而不是docx:
将文件另存为.xml而不是.docx;虽然你的文件变得更大(不再压缩),但你可以通过svn压缩节省空间,文本比二进制文件更有效率,我希望。
这似乎对我有用。
鲁道夫
答案 6 :(得分:0)
取决于设置。
如果它是您想要跟踪更改的短期文档,请使用Word内部控件。
否则使用SVN或Sharepoint或其他一些记录版本化文档的外部方法。如果不这样做,则存在任何人都可能在所有版本信息丢失的情况下覆盖该文件的风险。