Sorry; I missed this post.
SVN can handle any type of file. It works best with text-based files
(to capture diffs between revisions), but it'll work just fine with
binary files, too. You'll need to be careful between revisions -- SVN
won't be able to integrate changes from two different sources. E.g.:
- foo.odt is in the repository at r1
- Bob makes a change to foo.odt and commits the change at r2
- Alice makes a change to foo.odt *r1* and tries to commit
Alice's change will not be able to be merged back in because foo.odt
is a binary format and SVN doesn't know how to merge it in. SVN in
this case will detect the discrepancy and tell Alice that she can't
check in -- there's been a conflict that a human needs to resolve. So
Alice will need to get the new foo.odt at r2 and manually integrate
her changes in. Then she'll be able to commit it back to the
On Dec 12, 2007, at 1:26 PM, Richard.Friedman_at_[hidden] wrote:
> Finally I'm able to get back to this issue.
> Take a look at this website, which was suggested to me by one of the
> Sun folks involved with StarOffice and OpenOffice documentation:
> This site is home for the community of writers creating
> documentation for OpenOffice. There are some valuable tips on how to
> write documentation and how to use OpenOffice that we can very
> easily adopt for our project.
> It may be easier to think of archiving all the documentation in .odt
> format for now and publishing in pdf.
> Question is, can we work with .odt files or do they have to be in
> some ascii format like .xml?
> docs mailing list