Word/Openoffice 文档当前 SVN 版本的自动字段更新

Posted 2023-02-24

【中文标题】Word/Openoffice 文档当前 SVN 版本的自动字段更新

【英文标题】：Automatic field update of current SVN revision for Word/Openoffice document

【发布时间】：2009-04-23 13:28:09

【问题描述】：

Subversion 的“关键字”功能非常适合使用修订号自动标记文本文件。我真的很想为 Word 和/或 OpenOffice 文档做类似的事情。

我对 Word 文档进行了尝试，方法是在“注释”文档属性字段中插入“固定宽度”关键字替换。但它似乎仍然以某种方式破坏了文档（另外我不知道在多字节字符的情况下“固定宽度”可能意味着什么）。我也不喜欢这个主意，因为它不利于在文档本身的可打印部分插入数字。

我现在想象的是一个在文档打开时自动运行并更新自定义文档属性的宏。文档可能包含 doc 属性引用字段，这些字段会使用存储在 doc 属性中的值进行更新。

有没有人这样做过，或者做过其他任何事情来实现这个目标？对于 Word 或 OpenOffice？

【参考方案1】：

第一：Embedded Version Numbers - Good or Evil?：我觉得他们很邪恶。

您不应使用技术内部修订号来表示文档的版本。

“This is the 2.2 revision of my word document”与“this is revision 1567 of my word document”不一样。

从最终客户的角度来看，前者是一个“适用的”修订号。 从工具的角度来看，后者是“技术”修订号。

另外，如果它使用当前修订号修改文档，它仍然需要提交，这意味着存储的版本将在修订号中不同，而不是由您的宏更新的版本号。 如果没有提交，那么被这样标记的文档总是有可能不是完全最初从 Subversion 查询的那个。

---

话虽如此...关于更新 Office 文档属性的更一般性问题：

该线程 update word 2003 fields automatically 建议使用 Office API。 Microsoft.Office.Interop 不允许修改属性，但 VBA API 允许您访问要为给定 SmartTag 设置的任何 CustomProperty。

本文“To add a smart tag with a custom recognizer to a Word document”为您提供了 SmartTag 自定义行为的示例。

智能标签是附有类型信息的文本字符串；当符合条件的文本字符串出现在文档中时，它会被识别，并且用户能够执行适合该类型字符串的操作。

因此可以想象一个 SmartTag 能够识别字符串“revision for this document”，其自定义行为是“我将向 SVN 查询正确的修订号并显示它”

【讨论】：

感谢您的回答。至于嵌入式修订号是邪恶的，我是否正确理解它们不是天生的邪恶，而是因为 SVN 实施困难（例如更新和合并）？您已经说服我更新 doc-open 上的值不是更新的正确时间。文档可能与版本控制分离（例如，通过电子邮件发送给其他人），在这种情况下，值无法正确更新。所以它真的应该在从 SVN 结帐时更新。

查看我对您的回答的评论。

【参考方案2】：

你可以试试 Tobi 的小脚本： http://insights.oetiker.ch/windows/SvnProperties4MSOffice/

【参考方案3】：

我们实际上使用了一个有点相似的“系统”（由一位前同事创建），它解决了一些这些问题。

欲望...

我们希望能够看到两个打印输出实际上是相同的版本。 我们希望能够找到打印输出（包括修订）的来源。 我们希望消除由于作者忘记更新修订号而引起的问题。

解决方案

我们没有使用 svn 修订号，而是为我们的文档使用“人工”修订号。为了确保我们没有多个版本具有相同的修订号浮动在文档被修改时会自动更新，即会有几个从未发布过的“修订版”......猜测它并不完美......

半技术细节...

“人工”修订号存储在文档的自定义属性中。 我们已将所有word文档设置为requre lock (svn:needs-lock) 在锁定时，修订字符串的末尾会添加一个加号，表示“脏”版本。 在提交时，加号被删除，数字增加

结果

我们在打印文档中有一个修订号的系统：

除非文档更改，否则不要更改 表示脏版本，即从修改后的工作副本中打印出来 如果文档不同则不同（即作者忘记更新修订版没有问题）

【参考方案4】：

如果您将 Word 文档保存为 .xml（所谓的平面 OPC 格式）会怎样？

那么它只是一个文本文档，svn关键字应该可以工作。

【讨论】：

这当然是一个值得考虑的选择。但我真的不希望我的修订控制决定我的文字处理器选择。当然，修订控制不应该如此突兀。我在工作中使用 Subversion 和 MS Word（我都别无选择；我喜欢 Subversion 并且......我设法用 Word 完成工作）。

【参考方案5】：

VonC 的回答使我确信 doc-open 不是更新文档属性的正确时间。例如，如果文件通过电子邮件发送给其他人、复制了 CD 或“导出”，则在打开时无法更新其 SVN 版本。很难确保文件永远不会包含错误的过时修订号。因此，要“正确”执行此操作，应在 SVN 签出/更新时更新文件的修订号。

我相信对于文本文件中的 SVN 关键字，客户端会“摆弄”文件，在结帐时对其进行更新，并在提交前返回“规范”表单。所以对于 Word，使用客户端钩子来做同样的事情会很棒。 TortoiseSVN has client-side hooks, 但我认为其他 SVN 客户端不会。在我的工作中，我们几乎总是使用 TortoiseSVN，所以它可以很好地工作。

所以我想做的是写两个 TortoiseSVN 客户端钩子：

1) 更新后挂钩插入包含文件相关提交 SVN 修订的“SvnRevision”文档属性。

2) 预提交挂钩以删除“SvnRevision”文档属性。如果非 TortoiseSVN 客户端将其检出，这会使存储在存储库中的文件“干净”。 （它还可以防止合并冲突？）

---

更新： Arrr 我刚刚意识到另一个问题：如果我执行上述操作，那么 SVN 会认为文件已更改。嗯，这似乎很难。要使该功能正常工作，它确实需要与客户端进行相当紧密的集成。

【讨论】：

我相信元信息的“邪恶性”，因为该信息（SVN 修订号）不应该与您的文档相关。它与 SVN 本身无关，也与合并或更新无关。这是关于数据的信息部分（这是我的文档的“2.0”）和技术元信息（这是我的文档的“rev. 1597”???）之间的区别。后者不应该，IMO，被显示出来。

另一方面，SVN 很可能最终会存储多个具有相同“文档版本号”的修订（除非提交者在每次提交时更新它，这几乎肯定不会发生） .那么如果你在 SVN 中有几个版本都说“2.0”，你怎么知道哪个是“官方”2.0？