Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

This question already has an answer here:

I'm working on a website for a photographer, the whole code is just a few files, and whole repository is a few MBs without the actual photographs.

But, when I add the actual photographs to git and commit, then the repository jumps to 75 MBs. Considering the photos will be updated, the size of the repository is going to grow big as photos gets updated. I know I'm doing something very wrong.

Please, share your methods, for managing big binary files separate from source code, and still maintain dependencies.

PS: I don't use a db currently, all are plain text files.

share|improve this question

marked as duplicate by gnat, MichaelT, Kilian Foth, Yannis Rizos Oct 23 '13 at 10:43

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

4 Answers 4

up vote 1 down vote accepted

You might consider storing images in a submodule. This would allow you to keep code and images in separate repos.

My company uses submodules for our shared libraries, and though at times a little clunky, it may be the solution you're looking for.

share|improve this answer

The photos are original work, they need to be stored safely and reliably.

Options are storing revisions in a file name/folder or zipped tarballs with dates and times convention for each revision, a proper revision control or something in between. It is a fact that, beyond circumventing the first few laws of thermodynamics, as photos are changed and files added, the stored data will grow.

If you are prepared to discard old versions of the files to save disk space or otherwise reduce the size of the files you store, then GIT (and most other rev control tools) is not what you want.

If you want the certainty and control that a revision control tool provides, then you have to spend the money - Find the $100 and buy a 2 terabyte disk, I am sure your photographer would rather you do that than ask him to got an retake all the photos you just lost and cannot recover because you had a "whoops" moment at the keyboard.

As previously suggested, separate repo or sub modules will offer a nice solution of separating the data (photos) from the program source.

Whatever you do - make sure the photos are reliably backed up. GIT just happens to be wonderful for this task.

share|improve this answer
    
I don't really want to track versions on the photographs, but I think, keeping an automatic (possibly offsite) backup of the photographs folder is a good idea. The Problem is I need to maintain some sort of sync between the photographs and HTML code, since the photographs are not loaded programmatically, I've just hardcoded the paths, in plain old HTML. –  Sathish Manohar Aug 2 '12 at 17:47
    
"I don't really want to track versions on the photographs", is followed by a BUT that solved simply and elegantly by using GIT to store the photos. Don't use GIT to version control the photos, use it to store the photos. Your problem is then solved. Yes the repo will get big, but I can buy a Tera-byte disk for less than $100. Don't be so tight and buy a bigger disk - problem solved for $100.00... Only publish current photos up to the web server - GIT can manage that too...... –  mattnz Aug 5 '12 at 23:54

75MB is not a problem for git, but you might want to check out git-annex which looks like it can do what you want.

share|improve this answer

For web applications you may want to consider the Google Picasa services.

Or alternatevly manage your picture gallery in the Cloud. You may simply store the access link to that pictures, while getting them on your pages.

share|improve this answer

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