CODEWITHSUNDEEP
version-controlimage
orjan
orjan

Reputation: 1482

Version control of uploaded images to file system

After reading Storing Images in DB - Yea or Nay? I think that the file system is the right place for storing images. But I would like to know how you handle backup/version control of uploaded images in your different environments (dev/stage/prod) and for network load balancing?

These problems is pretty easy to handle when working with a database e.g. to make a backup from the production environment and restore the DB in the development environment.

What do you think of using for example git to handle version control of uploaded files e.g?

Production Environment:

Developer at work:

I think the solution above is pretty smooth for the developer, the images will be under version control and the environments can be isolated from each other.

Upvotes: 6

Views: 981

Answers (2)

Matt
Matt

Reputation: 2758

For us, the version control isn't as important as the distribution. Meta data is added via the web admin and the images are dropped on the admin server. Rsync scripts push those out to the cluster that serves prod images. For dev/test, we just rsync from prod master server back to the dev server.

The rsync is great for load balancing and distribution. If you sub in git for the admin/master server, you have a pretty good solution.

If you're OK with backup that preserves file history at the time of backup (as opposed to version control with every revision), then some adaption of this may help: Automated Snapshot-style backups with rsync.

Upvotes: 2

VonC
VonC

Reputation: 1326366

It can work, but I would store those images in a git repository which would then be a submodule of the git repo with the source code.
That way, a strong relationship exists between the code and and images, even though the images are in their own repo.
Plus, it avoids issues with git gc or git prune being less efficient with large number of binary files: if images are in their own repo, and with few variations for each of them, the maintenance on that repo is fairly light. Whereas the source code repo can evolve much more dynamically, with the usual git maintenance commands in play.

Upvotes: 2

Related Questions