Apache OpenOffice (AOO) Bugzilla – Issue 111919
Add an option to save uncompressed odt for version control (SVN,git,...)
Last modified: 2014-02-23 16:53:50 UTC
Version control (VC) systems like Subversion, Git and the old CVS are extremely practical programs that provide an unlimited undo function for documents. They also allow to reconstruct a detailed timeline of changes inside a document which comes in handy for documentation purposes in big development projects. All VC systems do so by saving the differences between the current and the last version of a document each time the user requests to remember that version. Some VC tools like svn can even deal with binary (non text) data in a relatively efficient way. The issue now is that if compressed data is kept under version control even if only one word in a document is changed big parts or even all of the compressed data tends to change. Which means that when writing a 600-page-document including 200 Megabytes of pictures and committing the data once every hour on a 10-hour-workday a compressed odt document might eat up 2 Gigabytes of server place each day. An uncompressed document on the other hand occupies only the place needed to store the text lines that actually have changed instead. Since these few kilobytes will be compressed by most VC tools whilst the compressed document won't get substantially shorter by being compressed again by the VC tool the user might end up with a even bigger difference between compressed and uncompressed document. There already is a extension to OOo that adds a GUI to control subversion from Openoffice.org without addressing this issue. A second extension I know allows to keep a single odt document in its own subversion repository (normally a whole development project is kept in a repository). But until now as far as I know openoffice lacks a solution for this problem.
*** Issue 111920 has been marked as a duplicate of this issue. ***
I don't think it's in the main purpose of OOo to support this. At least not as core feature but as extension. Reassigned to Requirements
Sounds like a brilliant idea to me - but surely GIT, SVC etc. can have input filters to do the uncompressing before the archiving? That said, it can't be too hard to add as an extension.
Input filters for the version control tool would work, but have the disadvantage that everybody that takes part at a project needs to install them regardless which svn client he is using (subversive and subclipse under eclipse, tortoisesvn, rapidsvn, subdiversvn, the svn command line tool,...) and regardless of the platform (CentOs, SunOs, Ubuntu,Microsoft Windows,Apple OS X,...). --- Only to make sure there won't be any misunderstanding: Compressing the whole directory structure of a document into a single jar (I think it was jar - or is it ZIP?) archieve before saving it as a file with the extension .odt is still a good idea with modern version control tools. What I would need is the possibility to set the compression level of the jar archiever to 0 instead of maximum. When using fastjar for archieving the "-0" switch would do this trick.
*** Issue 114773 has been marked as a duplicate of this issue. ***