What documents should be stored in version control and how should they be stored? [closed]

Answer 1

For Word documents, try using RTF (rich text format), which is basically text. Another possibility would be HTML. They're text, so you should be able to do diffs on them.

Most Wikis are distributed in that they're designed for collaboration. I think you're really asking about whether there are hosted solutions or do you have to manage them. Take a look at http://www.atlassian.com/.

Answer 2

Most document formats don't play terribly well with source control. Almost everything you list is either effectively a binary format or convoluted markup that won't diff well. As long as you just want versions of documents and don't care about the diff, use whatever format you like. I prefer Microsoft Word documents because you can use the built-in change tracking and comment system to track deltas between documents.

As for what documents to store, I would recommend storing anything you'll have a use for later. What documents could be used by someone to continue the project should you leave? What documents would be helpful to bring a new person up to speed? This means specifications, but not documents like burndown charts.

To answer the wiki part of your question, check out DokuWiki. It stores everything in text files so they would be very easy to add into a source control system.

Answer 3

For OOo, word documents and other binary files, you should have a look at pro-git http://git-scm.com/book/ch7-2.html

Answer 4

I've just lived with the fact that I can't track changes to binary file formats through a version control system, but I use it anyway since it is useful. Note that typically most of these types of files are work products that will be released (user guides, docs, etc.)

For early project artifacts like requirements and initial designs, I tend to use text documents - not because I can track changes, but because I like to use my IDE for it.

I have never really been "bitten" by the fact that a change can't be "diffed" in version control. The commit comments and other documentation guidelines around changing an important binary document usually make up for that lack of visibility - in that there is another trail if you look for it.

I agree this is not ideal, but I don't think it is really worth fretting over.

Perhaps I just got used to the idea of a set of files I would be able to track as much as I would like.

I put a lot in version control, but also use defect tracking for some things with lifespans that are temporary.

Answer 5

Git can handle binary files just as well as text files. Instead of explicitly storing diffs, Git stores the entire previous revisions of files in the repository. The repository objects are then compressed to save space. Diffs are reconstructed on the fly whenever you ask for them.

So considering only disk space, there is little difference between storing an XML Office document uncompressed in Git, and storing a zipped version of that same document. The only difference would be the relative performance of Zip vs whatever compression Git chooses to use.

Answer 6

My company stores Word documents in SVN, and accesses them via TortoiseSVN.

Tortoise uses Word's built in change tracking function to show you a "diff" of two revisions.

This works really well, but requires Windows and Word.

Edit:

You could probably get this working with git too. If you install TortoiseSVN, then look in %PROGRAMFILES%\TortoiseSVN\Diff-Scripts\, you'll see what tortoise is doing.

If you're using git, I assume you're 1337 enough to hack it to work for you :)