OpenDocument files in hg?

[Frank A. Kingswood]

John D. Mitchell wrote:
> On 9/6/06, Thomas Arendsen Hein <thomas at intevation.de> wrote:
> [...]
>> I thought about the same and unzipping into a directory would be the
>> best I can imagine, too. But you're right, this is not supported by
>> encode/decode.
>>
>> Stefan Monnier suggested converting to a .tar file and I had the
>> same idea. This way you get diffability for most content. A similar
>> approach would be to convert everything to a single rfc822 file with
>> mime attachments for the contents of the original zip.
> 
> Bursting .zip/tarballs/odts/etc. would be better than the mime because
> we'd get better handling of mixed binaries and text files and clearer
> diffs, etc., right?

The original feedback was that the XML files would still not merge 
correctly. This may be so, but is a separate problem.

If hg can support a filter that explodes a file into constituent 
objects, then this could be used to layer the required functionality on top.

*Assuming* that it is acceptable to unzip and later re-zip the OOo files 
(with possibly a different document md5sum as a result of differences in 
the compression), then other transformations can be done at the same 
time. In particular, the XML content and styles could be run through an 
XML beautifier (like OOo itself does when you untick the Size 
optimization for XML format). This would make document changes 
relatively simple to diff.

The second step is then to find an XML merge tool that can merge XML 
documents either automatically or user-assisted if there are conflicts 
or the changes are too difficult for it to understand.

Finally, I could well imagine that someone *really* determined could 
make this merge tool show the merge as an OOo document with revision 
markers. I'd be happy with step two myself.

Frank Kingswood