8

It's not uncommon where I'm working on a site that includes things like binary (or effectively undiffable due to factors outside my control) specification documents (e.g., PDFs, Word Documents, Excel Spreadsheets) and multimedia source files (e.g., FLA source files, Photoshop files, Illustrator files).

How should these be stored?

My instinct is to just throw them into git. Storage is cheap, but it does make the clone operation take much, much longer than it otherwise would.

A potential alternative would be to use a wiki. I've tried it in some cases but never ran into a case where the wiki format's inherent strengths (layperson-accessible version history and easy access to latest copies) have or would have led to enough benefit to justify the additional work in maintaining the wiki.

The third option is to just let them hang out locally and in email threads.

So what approach should I take to this?

Improve this question
4
  • 1
    You could create a separate git repo for storing this kind of data. – blueberryfields Sep 18 '11 at 3:42
  • 1
    That's an interesting idea. Better yet, perhaps you could even submodule the documents. – Steven Sep 18 '11 at 4:15
  • 1
    Note that this won't work well for files that are really large (as in, hundreds of megabytes). Last time I checked, if you try to store a 500MB file in git, it'll use 1GB of RAM. – Joey Adams Sep 18 '11 at 4:27
  • I store every asset in the repo that is needed to build the project. I don't care if it's inefficient, I want one clone operation to be enough to get everything and not have to hunt down 3rd party libs and media from other sources. – Tamás Szelei Sep 18 '11 at 10:45
3

we're using a wiki for this (confluence), used to be versioning, and it's been an extreme pleasure to work with. The level of organization a wiki gives you is just not reachable using directory trees (what you would be doing using git/samba) or email. Also think about scalability and the future: git might work now, but would it also in 10 years, when there are x more documents? Another huge benefit: have a quick idea? just find a suitable place and start typing. You don't even have to publish in the first place.

Improve this answer
2

I'd say it depends how you are using that data:

  • if you are improving it heavily and frequently, use the advantages of modern revision control systems. But think about the structure and modularity of your repositories (who is going to use the revision control system in what way).
  • if the documents are barely updated but heavily used for look-ups, a wiki is a great solution and worth the effort.
  • if neither is the case, use a cheap and simple solution. I'd still go with a local place instead of email-attachment-chaos, but a (samba-)directory or files/links within your wiki/issue-tracker/wordpress/... will do.
Improve this answer
1

The approach that you take depends on your team and the process methodology that you are using. Whatever fits best into your workflow is what you should be doing. You do want these artifacts to be versioned and managed, just like the code. Email doesn't easily provide that, while a version control system and most wiki software does. Ultimately, you want to be able to link a specific revision of the software with specific and accurate artifacts that describe that revision of the software.

You mention that you create some documents in Microsoft Office. Office products have change and review tracking built in. Although you still need to version your documents on top of this, the changing tracking will allow you to see how a document has progressed over time. I would recommend learning about this feature and seeing how you can make effective use of it within your process.

You also mention PDFs. I'm not sure how you use PDFs, but if they are generated from other files, version only the native file. It probably doesn't take that long to go from a native file into a generated PDF. This really goes for anything that gets generated from other sources. Don't keep generated products, only what you use to generate them as a versioned artifact. It'll save space and help you maintain your sanity.

Improve this answer
0

First off its a really good idea to get all this stuff under version control!

The tool you use depends on the type of data. For multimedia files zipping up the originals and dumping them in a folder would seem to be the best option, perhaps, with copy of the cover document going into your main version control (git or whatever).

For word documents like use cases and specifications etc. I think the best strategy would be to store them in one of the newer "xml" based formats and store them in "git". The "diff" would actually mean something then, and, although the documents themselves would be larger the "diffs" would be smaller.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.