I am a software developer at heart and by trade, and spend a lot of time in development tools... One of the more useful development tool types is version control, and for the uninitiated, it works something like as follows:

  • Create a file
  • Start working on the file
  • Check in the file (create a version 1 of it)
  • Open the file and edit again
  • Check in again (version 2)
  • Realize you deleted something important from version 1, go back in time, get the thing you deleted...
  • ...
  • Profit...

Anyway, I am wondering if something similar is used with photos? Essentially, I was thinking something along the lines of:

  • Import Photos (V1).
  • Start tagging photos (V2... XMP side cars should only really change here).
  • Start adding stars, more tags (V3)
  • Start adjusting some settings (V4+)

With the flow above, you should be able track a lot more changes... and give you some sort of backup strategy...


11 Answers 11


Photographic workflow applications such as Adobe Lightroom and Apple's Aperture provide this sort of history as a built in part of their functionality.

When you edit a RAW file in these, no changes are ever made to the original image. Instead, they are saved as 'instructions' separately. Thus, you can see a history of all changes made, and with a click of a mouse go back to any previous point in time non-destructively.

If you are just using Photoshop, then this does not happen, and you would have to manually save different versions of your photo before working on it each time.

(I'm guessing there's no reason you can't use an SVN repository for photos?? ie. Binary files?)

  • 1
    \$\begingroup\$ Lightroom keeps history of an editing session, but does that history persist if you close Lightroom and reopen the image from the catalogue at a later date? I know you always have the original RAW file, but can you arbitrarily get a version somewhere between the original and the latest at any time? \$\endgroup\$
    – MikeW
    Commented Feb 15, 2012 at 9:36
  • 2
    \$\begingroup\$ Yes! The only time it would get deleted is if you delete the image from the catalogue, and re-add it again. Then you'd be starting from scratch. But otherwise, the history is maintained. \$\endgroup\$
    – Mike
    Commented Feb 15, 2012 at 9:37
  • \$\begingroup\$ Digikam provides the same functionality of instructions. \$\endgroup\$
    – Unapiedra
    Commented Feb 15, 2012 at 9:38
  • 4
    \$\begingroup\$ In addition to the history log, Lightroom lets you create a "snapshot", which lets you assign a label to the current development settings and get back to it easily. Sort of like tagging in SVN. lightroomkillertips.com/2009/whats-a-lightroom-snapshot Some tools, like Jeffrey Friedl's plugins, can be configured to automatically create a snapshot whenever you export to services like Flickr. regex.info/blog/lightroom-goodies [I wrote this simultaneously with fzwo... sorry for any redundancy with his comment.] \$\endgroup\$
    – coneslayer
    Commented Feb 15, 2012 at 12:56
  • 2
    \$\begingroup\$ If you want full version control functionality, you can just source-control the sidecar files just like any other file (they are a markuped text internally). Then you are not restricted to history, but can make "branches" with completely different types of effects, if you wish to. The software should allow you to apply a new sidecar file to any given RAW picture, at least mine does. \$\endgroup\$
    – rumtscho
    Commented Feb 15, 2012 at 13:33

Virtual Changes

I use Lightroom v3 and this product has a non-destructive workflow. This allows me to do changes to my image(s) in a virtual sense.

Version Control

I then use SVN to maintain control the Lightroom Catalog (Just a simple SQLite DB) and this essentially gives me version control over the virtual changes.


I have RAID 6 setup that holds the media for redundancy and a cycle of USB drives as a rotational back up system.

While this may not work for everyone, it works for me. Plus it allows me to use several machines and have the same LR catalog (using the svn commit/update cycle).

Excerpted from blog post Here:

I have Lightroom on a couple of computers with a RAID 6 based server and I have been struggling on how to synchronise everything to make my life easier between machines.

After some decisions I have now moved my photos to the \server\share and the catalog is tracked via subversion! This makes everything so much easier between machines.

What I have done is created a repository that holds the Lightroom catalog. I have added an exception to not include the preview files as subversion has some issues with them.

Now my steps are as follows:

Update subversion
Run Lightroom
Import pictures
Move images between local drive import and the media file share
Make any required changes
Exit lightroom
Commit catalog
That's it!
  • \$\begingroup\$ Cool. So, your SVN server only holds the catalog, and your file server holds the real images... and the catalog points to the files on the server? correct? Might try this out. \$\endgroup\$
    – TiernanO
    Commented Feb 16, 2012 at 22:19
  • \$\begingroup\$ @TiernanO - Correct. That is how I have setup my infrastructure/workflow \$\endgroup\$
    – Wayne
    Commented Feb 17, 2012 at 1:36
  • \$\begingroup\$ thats cool. Currently importing about 200Gb of photos now into a single Lightroom catalog, and will start playing with this idea... hopefully it will do what i need it to do! Thanks for the tip! \$\endgroup\$
    – TiernanO
    Commented Feb 17, 2012 at 7:11
  • \$\begingroup\$ @Tierno - You should be ok with that. I believe any limits experienced are going to be around SQLite constraints which as a developer am sure you can research. (FYI: SQLite Manager for Firefox works great at looking at this catalog) \$\endgroup\$
    – Wayne
    Commented Feb 17, 2012 at 10:53
  • \$\begingroup\$ @TiernanO - Would be interested in knowing if this did indeed work for you like it has done for me \$\endgroup\$
    – Wayne
    Commented Apr 7, 2012 at 9:33

I think you may want to use git-annex (to manage photos and backups) along with a bup remote (for versionning). I'm currently looking into it myself actually.

git-annex keeps track of your files using git, by committing symlinks to your files. The files themselves are not added to the repository. Once your photos are "annexed", if you clone your repository (on an external hard drive for instance), you can ask the clone to retrieve the files (or part of them) associated with the repository on the hard drive. git-annex keeps track of which repository has a copy of every file. This way you can split a backup on two small hard drives and be sure that no photo has been forgotten.

Say you're on a trip. You have taken photos which are copied on your laptop. You can clone the git repository that is on your ssh server at home, sync with it, add your local photos to git-annex to your collection, and push the changes back to your server. Then, you push the files themselves.

git-annex keeps track of the changes in your collection, but only keeps the last version of your photos. For file versionning you can add a special bup remote to your git-annex repository. I haven't looked into it yet because I'm not sure I need it, but it should do what you want. See this or this.

  • \$\begingroup\$ edited my answer. \$\endgroup\$
    – barsanuphe
    Commented May 30, 2012 at 21:18
  • \$\begingroup\$ also, the developper behind git-annex is currently holding a kickstarter to make things easier for the less technically inclined. \$\endgroup\$
    – barsanuphe
    Commented May 31, 2012 at 16:31

I use Lightroom to do image editing and keep a version history. If you're looking to use Photoshop, version control is sort of almost built in: Adobe Drive and Version Cue. I think Version Cue is only a part of the Creative Suite, FYI.


Pixel Novel will plug in to Photo Shop and works with any Subversion servers you already have or I think you can purchase a repository from them.


They call it "Version control for designers"


I use Photoshop and Adobe Camera Raw instead of Lightroom so I use version control for the XMP files that strore my raw conversion settings in order to track changes. This works really well as the XMP files are just XML. It's handy to do all the colour corrections first, check in the XMP files and then do any cropping to nonstandard aspect ratios. That way I can quickly revert to an uncropped version if I need to print images in the original 3x2 aspect.

I know Photoshop has its own built-in revision tracking system but it's a case of using tools I know better. There are other coding tools that are useful such as build scripts/build automation. I can for instance issue a single command to "build" a set of photos using uncropped XMP files targeted for print that will convert process rename and output all the images from a set. It's really easy if you already know how to do it for software!

You can add binary files to a repository but this requires a lot of storage and you don't get any useful diff information when comparing different versions.

This is for regular raw conversions, setting exposure, colour balance etc. For more involved Photoshop work I do as much as I can non-destructively with adjustment layers and smart filters but I've not yet got to the point where I can do everything non-destructively so for the time being I just save several versions of the .PSD file.

  • \$\begingroup\$ you can set lightroom to use XMPP files too... i used this before, and works grand. \$\endgroup\$
    – TiernanO
    Commented Feb 15, 2012 at 17:36

I am also a software developer and tried using Git and SVN for large RAWs and XMPs just for the ability to sync my pictures between removable drives and version the XMPs. It was unbearably slow and got slower over time as I added more files. I also use Lightroom for history, so I went back to rsync.

Now, I am also looking into git-annex and so far it is nice and fast. It also has the added benefit of checksuming each RAW file, so you can see if a bad HD has messed up your images since import. This is a massive benefit to me, as I can test my backups to make sure they haven't degraded through copies/bit rot. I plan on versioning the XMPs only and annexing the RAWs. git-annex can do the legwork of knowing where things are, and I can be sure everything is on my server getting backed up as well as have a working copy on my laptop if I want.

You can also have an Amazon Glacier remote, so I've read, but I haven't tried this out yet.


Check out our Daminion. This is photo management software (multi-user friendly) that supports version control for your archived photos and other media formats.

Daminion Version Control

The single user Daminion version is free so you can download and check it right now.

  • 14
    \$\begingroup\$ Hi Murat! You've been around for a while, and your posts on Daminion are generally on topic and helpful, and include the proper disclaimer of affiliation. But I can't help but notice that all of your answers are suggesting trying Daminion, and, from the FAQ: "If a huge percentage of your posts include a mention of your product or website, you're probably here for the wrong reasons." Please consider writing some answers for questions unrelated to your product. \$\endgroup\$
    – mattdm
    Commented Feb 15, 2012 at 14:12
  • \$\begingroup\$ Thanks for the explanation, Matt. No problem. But as you correctly noticed all my posts provide helpful answers to the questions. \$\endgroup\$ Commented Feb 16, 2012 at 9:35

I don't, and probably will not ever use source version control like Git or SVN because of the sheer size of the files involved. Each raw file is 20-30MB and changes often touch every pixel in the entire image reducing the effectiveness of just "tracking the changes".

For a single image I could easily see a 200MB SVN repository instead of perhaps 60MB if I was just to save a copy of the original and a copy of the final image.

  • 3
    \$\begingroup\$ if you are using RAW files, you should not be changing the actual RAW image, just XMP side car. If you are changing the RAW image, GIT only saves the changes, not the full file... GIT may not be the best option (SVN either) for this since they are large files, but there are a few options that work well for large files... \$\endgroup\$
    – TiernanO
    Commented Feb 15, 2012 at 17:38

Here's a plug for Apple Aperture. The beauty of Aperture is that it has about 95% of the functionality of Photoshop that photographers desire (you can't make flaming text with it, yawn), and that editing is version-controlled in a very lightweight manner.

This works with JPEG and other image formats, as well as RAW format.

You can even do a "round trip" with external editors, such as Photoshop, but these necessarily save an entire copy of the image, rather than a lightweight filter that is applied to a master image.


There is a good discussion of this here: https://www.impulseadventure.com/photo/flow-catalog-versions.html

There are significant differences between code repository and image DAM.

  1. Image use tends to be a multi-branch tree. While you do have branches in code, the goal usually is to minimize them. In image use you can end up with situations like this


--- Cropped and sharpened.

--- --- Reduced resolution for Facebook

--- --- Large thumbnail for gallery

--- --- Medium thumbnail for gallery

--- --- Small thumbnail for gallery.

--- --- Large version with watermark for gallery

--- --- --- Black and white version with watermark

--- --- --- Black and white version

--- --- Special crop for client.

--- --- Adjusted color cast for different client

(I did one web page were each image had 18 different resolutions.)

  1. Code tends to have small differences between versions. In a typical checkin only a few percent of the code changes. In an image most of the pixels change some, and the space saving from storing only changes is small.

  2. In a code repository you are concerned with the bit level changes. A line of code here, the value of a constant there. In image manipulation a history of the steps you did is more significant.

  3. Image work tends to be much less collaborative than code. While graphics artists may take an existing image, and layer graphic artwork over it, most images are managed by one person through out their life span. (This is different in video/film.)

  4. In software the fundamental level is the project A single class file doesn't mean much without the rest of the project. In image processing the image is the fundamental unit. You can spend your entire life working on a single software project (Microsoft Word...) In photography you rarely spend more than a few minutes on an image.

  5. In software the important task is to be able to track changes and revert back to a prior version. In image processing the important task is to be able to find that image and its derivatives at a later date.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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