When playing with Adobe Lightroom 3 and Subversion, it quickly became obvious that the committing changes to the Subversion Repository takes quite a bit of time for large files and/or large numbers of files. Also, any commit duplicates the versioned files (that is the essence of version control!) but you do not necessarily really need a new version any time, especially at the beginning when you are working with the files and get them into your photo repository.
Getting your Photos into Lightroom
This is not supposed to be a Adobe Lightroom Tutorial, still I want to share some thoughts of how to fill your repository (the one under version control) with data using standard Adobe Lightroom 3 functionality. So the initial assumption is this: somewhere, there is a bunch of digital images sitting around on either some harddisk, memory card or CD/DVD and I want to get them into my Photo Vault (which is the name I have given my subversion repository). In order to do that, I have set up a Subversion Repository on the server and linked it to a local directory called Photo Vault.
The first category level in my Photo Vault is the image owner – there is obviously myself but there are images from other sources in my vault that I do not want to mix into my own photos.
So let me import the first set of photos which are currently located somewhere in a server-side harddisk.
When I am selecting the source for the import operation, I can point to my server-side directory. Adobe Lightroom 3 will then analyze the photos within this directory (and its sub-directories if I want to) and propose the structure it is creating in the destination directory (depending on my settings).
One of the neat features of Adobe Lightroom 3 is the ability to create that structure based upon the timestamps of the photos – so I can create something like <yyyy>\<yyyy-mm-dd> as directory structure.
While this is exactly what I need, there is one little problem with this: I am using multiple cameras and I do not want to mix the pictures of different cameras into a single directory as I would if I would just use the automated directory creation process.
The picture to the right shows the expected structure based upon the analysis of my selected set of photos.
So there are some ideas on how to get around this:
- I could create a directory for each camera within the Fotos Andreas directory. That would then separate each camera’s photos from each other.
- I could create a Collection Directory (e.g. Vacation 2011 – Nikon D90) in the Fotos Andreas\2011 directory and then put the pictures within it. That would allow me to keep the pictures in one directory based upon years and then split up in a manual process.
- I could ignore the fact that I am using different cameras, rename the files in import to make sure they get unique file names and import them all into a date-based hierarchy as the system is currently proposing.
One thing that should not be forgotten is the following: we are talking about a storage of the raw data. The files will be located in these directories but they will most likely rarely be viewed from within these directories.
So instead of creating a storage structure that partially does what I can achieve later by building collections (or Albums, as Picasa would call them) I will focus on doing what I want to do: store my files.
If I do not want to mix distinctive physical properties of my photos (“Which camera was it taken with?”) with logical properties (“Who took it?” or “What was the story behind the picture?”) then I would have to revisit my idea of having the photographer as main category, wouldn’t I?
Which approach you would use in your own situation might be different – I have decided to use the most technical one, using the physical camera as main category. Primarily also because the approach with the Photographer will cause a different problem: what if (like in my case) one camera is used by more than one photographer?
It will also help to later apply camera-specific operations (especially when you treat a slide-scanner as a “camera”) to the set of photos.
Nonetheless, there is another Adobe Lightroom 3 Feature I would like to use during import. I am not only owning a Nikon D70, I am also owning a Nikon D90. Both cameras are creating their files with a continuous counter (once you configured the camera accordingly!) but both are using the prefix DSC_ to name the pictures. This, unfortunately, does not seem to be configurable and the result is that both cameras might be using the same file name for different files. In order to avoid problems when later-on using such files in one compilation, I am telling Adobe Lightroom 3 to rename the files upon import, replacing the DSC_ with a D70_ or D90_ to make them distinct.
So when all these settings are done – and I am deliberately skip any other options I am having during import – my files are now located in my Photo Vault directory. As you can see by the missing green check-marks, they have not been put under version control yet – they simply have been copied into the repository directory!
Why is this important? Well, because of two things:
You still have to manually add them to Subversion and commit them – otherwise, they are nothing but local files and that somewhat defeats the purpose of the version control exercise!
And secondly: this is your change to make additional changes to these files without having to create a new version (and thus duplicating the storage space needed for them!).
Making additional changes before applying Version Control
If the idea of version control is to track any changes to files then why would you do something before applying version control? Well, the answer is simple: to save space on the repository.
The whole idea of having version control is to prevent unexpected, involuntary changes to the data and not detecting it if it still happens.
In my current situation, I am working with the data and if anything should go wrong, I can still re-import from the media I have used used (I copied the files, I did not move them on purpose!) – so if anything goes wrong now, I will most likely detect it and I can still correct it.
So what would be an additional change that I would like to make at this point in time? One has already taken place: the files have been renamed to their new naming scheme but if I had not done that upon import, now that would be one change to make before committing the files to Subversion.
Another one is meta-data enrichment: I have imported photos for which I am having a GPS Track recorded. My camera does not have a built-in (or add-on) GPS so if I want to geotag the photos, I would have to do it now. Since the topic of this post is not about geo-tagging, I have described this process some other place but trust me: it is quite cool!
I cannot see my changes in Adobe Lightroom…
With the process described above, I have added geotags to my photos. Now if I go back to Adobe Lightroom 3 and examine the EXIF Information of the images, I cannot see the geotags in there.
The reason is quite simple: the EXIF Information has been read from the picture upon the time of import – and that was before I added the geotags to the files in the repository.
Two things become obvious: Adobe Lightroom 3 needs to refresh the EXIF Information now – and the files have really changed since the geotags have been added to them.
In Adobe Lightroom 3, select the images for which you want to re-read the EXIF Information. Then choose Metadata -> Read Metadata from File from the menu.
Adobe Lightroom 3 will now process the selected files and once finished, you will be able to see the meta-data information including the geotags in the EXIF Information window.
From there, you can even click the little arrow next to the GPS Information to open a browser indicating the position in Google Maps.
So this has now been taken care of. Back to the original topic of digital photos and version control!
We are now having the images imported into our file system directory which is linked to the Subversion Repository. We have included these files in Adobe Lightroom 3 so the information about them it in Lightroom’s database. We have enriched these files with additional information – in our case the GPS Information. By all means, these files are physically ready to go under version control – there is nothing more to do to them right now.
Putting the Images under Version Control
In order to work with Subversion from my desktop PC, I have installed Tortoise SVN as a client application. That gives me the nice overlays in my Windows Explorer as well as the most frequently used commands at context menu level.
So in Windows Explorer, select the root of the directory branch you want to put under version control, then choose Tortoise SVN -> Add from the context menu.
You will have to go through a couple of windows telling you exactly which files will be added and where you are in the current progress with respect to all files you are adding. Once done, your files and directories will be marked with a blue plus sign – that is the indicator that upon the next commit operation, these files will actually be copied into the subversion directory and are under version control from then on.
When you are ready to commit the files, select SVN Commit from the context menu.
You will be asked to enter a commit message – you do not have to but it is recommendable to do so if you later-on want to understand why a specific change has been made.
Once you click the OK button, the process of committing will take place. And it can take some time because all these files are now transferred to the Subversion Server and that will take a little while. In my case, we are talking 460 files of 1.16GB altogether – the commit took about 10 Minutes.
A Word of Warning
With the images now under version control, there is one thing that you should not do any longer: do not delete, move or rename the files using Windows Explorer! Subversion will not be able to track the files if you start moving them around – if you have to, there are Subversion methods (integrated into the Windows Explorer) to do so but do not use the standard Windows functionality or equivalent functionality of other programs! Especially, do not use Adobe Lightroom 3 to batch-rename the files once they have been placed under version control!