How should I save a file in OpenOffice so that it is not a binary file in Subversion?

Question

I'm working on an Open Office document with a partner and we are using subversion to collaborate on it. However, we are saving the document as a .odt file and subversion reads this as a binary file type. Therefore it has me worrying that when we go to merge the files and the diff pops up that we will not be able to adequately perform the merges if there are conflicts; we won't be able to understand the raw .odt file.

So my question is "How do I save a document in Open Office so that it retains all of the formatting you would expect and want but does save as a binary file and therefore can be easily merged?"

Or am I using the wrong method to do this? (Which is more than likely)

Answer 1

For complex binary file formats (of which .odt is one), I have found that it is a good idea to use locking in Subversion and not try to merge changes. Set the Subversion property svn:needs-lock on the file and you will then be required to request a lock on the file before you edit it (see Locking in the Subversion book for more details). This has worked well in my situation but it depends on your level of collaboration whether it will work well for you.

Answer 2

The .odt files are AFAIK zipped XML files. However even if you would save them as unzipped XML I seriously doubt that you could do merges of anything but the smallest changes.

Answer 3

The .odt format is actually a zip file format (in most cases), which packages up your document and possibly other binary resources. The fact that it's a zip file, means it's inherently binary. There may be a way to save the document in plain-text XML using OpenOffice I'm not sure.

If you really need the ability to merge changes, you'll probably be better off with a plain text format.

Answer 4

As much as you might hate it, LaTeX provides you a means to create documents, but maintain them in subversion as text, which is easily merged.

Aside from LaTeX or just keeping txt documents, setting a Lock on the file with Subversion is your best bet.

Answer 5

Merging a complex page will be a problem, as subversion won't be able to do a good job.

By locking, only one person can work on it at a time.

You could save it as an html page each time, if you don't like the LaTex or .txt suggestions.

You could write some plugin for OpenOffice that will allow collaborative work, perhaps.

Answer 6

A file doesn't have to be a text format to be diffed and merged—as long as the vendor provides a good diff and merge tool. And as long as the VCS can be configured to use these external diff/merge tools. However it's rare to have such diff and merge tools provided for proprietary doc formats.

TortoiseSVN can diff Word docs and that's extremely handy. It can apparently merge too, although I've never tried that. I think it may be able to diff and merge OpenOffice docs, but I've never tried it.

TortoiseSVN can "sort of" diff Excel docs, but it's not very nice to use. No merging.

At my company, we set svn:needs-lock on Word and Excel docs to avoid merge troubles. Even then I find it very handy to be able to diff previous revisions and see what changed.

Answer 7

Complex machine-maintained files will always be hard to merge in a version control system, even if they're stored as text. What if it were uncompressed OpenOffice.org XML? A simple change you make will modify lots of lines throughout the XML file, resulting in possible conflicts.

Your best bet would be to use a simpler format, such Markdown, because a simple format leads to less changes, which leads to more reliable merging. Many writers use Markdown and it's easy to learn.

There are tons of editors that support this markup language, but you may have to modify your workflow a bit. There is for example a ODT to txt conversion script, that converts ODF to txt with markdown formatting. Also, pandoc can convert between many formats, such as Markdown and ODF.

So there are two options:

1. Change to an editor that directly supports Markdown (a simple text editor will do, but you could go for a more advanced text editor with Markdown mode such as VIM Markdown mode)
2. Insert a conversion step between Markdown and OpenOffice.org format. (make sure to test the viability first)