I strongly support this. Version controlling OpenDocument files is troublesome, adding revision control system hooks would be difficult and tedious. A more straightforward operation would be having the OpenDocument application do some kind of operation like allowing save the file uncompressed, so changes are more easiliy tracked.

This latter could be done with koffice easily, but you would have problems opening that files within OO.org.

As what OO.org concerns, the ooosvn project seems to fill that hole. My skills haven't been enough to understand what it exactly does, but even from the integration of bash shell scripting+Basic+openoffice could be a good work, I think that combination must not be the best option for an opensource based solution to the version control of OpenDocument files.

Yet I think some joint effort should be thought and implemented to solve the issue.

@Richard

I see multiple problems with the oosvn-implementation;
1. we can't use it since it's written in OOo basic as OOo-package and therefore accesses OOo/UNO-API functionality.
2. it is not portable since it uses shell-scripts
3. it's just a wrapper around the svn-commandline tools (ok, propably not really a point or at least it's open for interpretation if that's an advantage or a disadvantage :)

So, im(h)o 1. already disqualifies it since to provide a "compatibility layer" to wrap such basic scripts wouldn't only mean a lot of work and a lot of additional code but we would need to get a to OOo-basic compatible basic-interpreter done. That sounds much more work then writting an own solution, to reuse portable code that already exist e.g. at KDevelop4 or to improve the already (at least partly?!) existing code in KOffice ( http://code.google.com/soc/kde/appinfo.html?csaid=D2A89C79513DB3E5 and http://dot.kde.org/1157452184/ ).

@Raúl

KWord is able to save uncompressed OpenDocument Text files since ages ;) I agree about the joint effort part but currently OOoSVN looks strong like OOo-only :-(

So, let's mark this wish as WONTFIX for now since the current OOoSVN-implementation just looks like OOo-only.
If anybody does not agree there, please feel free to reopen the wish + provide some more details why I am wrong with my opinion.
If it's all about getting a "joint effort" established to provide a solution other Office-suites like KOffice are able to use, then I would suggest to start first to define how such a solution needs to look like (e.g. what language, how to let apps access the functionality, maybe implement a lib? and what is the advantage compared to use the libsvn direct - e.g. provide support for more backends then only subversion? etc.).
So, as sayed, I absolut like the idea to have here a solution that could be used by much more apps and it's a very good idea! I just don't see how it could be done with the current implementation :-(

@Sebastian

would you mind to re-open the with, but with an changed title?  I would like
to have the title: "add revision control to kword".
Of course other koffice apps, may get revision support but kword is the best
target for this.  It would be great to see the shell script changed in 
qt scripts and the OOo only code into dbus calls.

ooosvn shows that revision control is now possible, and it can be taken as
an example.  I'm looking forward to a good and real revision control for word
documents.

Ah, you what I will re-open the wish and leave it up to Sebastian to leave it
open or close it again.

Its an interresting approach, lets join it with the kword bug for that feature then. (You didn't think you were the first, eh? ;)

*** This bug has been marked as a duplicate of 120676 ***