How to use Subversions for Indesign, Illustrator and Photoshop

Question

I found the tool Timeline from Pixel Novel, but I wondered if I could use any subversions app to manage my design files. I'm not sure to understand everything about Subversions yet, and I did not found a lot of information about his usage in the design field.

Answer 1

Not sure how well it works with data compression, but you may want to give git annex a try: http://git-annex.branchable.com

If your files aren't so big, plain git or mercurial may be the best fit. Just avoid SVN at all costs

Answer 2

There's a few good suggestions at https://stackoverflow.com/questions/29292/version-control-for-graphics

Here are a few quotes from the question at http://StackOverflow.com

"Github recently introduced "image view modes", take a look: https://github.com/blog/817-behold-image-view-modes"

--

"I've had success with using perforce on very large projects (+100 GB), however we had to wrap access to the version control server with something a little more artist friendly."

--

"TortoiseSVN can show image revisions side-by-side, which is really useful. I've used it with different teams with a great degree of success. The artists loved having the ability to roll back things (after they got used to the concepts). It does take a lot of space, though."

Answer 3

Timeline works with "any svn" and is apparently an indesign plugin as well.

SVN is probably mostly off topic here, but in a nutshell, it tracks a single origin file and then stores changes to that original file as time goes on or you force a new "basis point."

The only way to reliably revert to an older version is to compare them manually and decide. Repos were originally meant for plain text files (source code) mostly, and it is pretty easy to look at raw changes and decide which you want because they were human readable to begin with, but for binary data (images, proprietary formats, container formats etc), the changes are not in a human readable form. Timeline looks to be a way to handle this by taking the various commits and displaying them.

Scott's link to GIT image is meant for specific formats and (I am guessing) probably does not support PSD files and especially indesign files (i.e. random binary formats). Timeline seems to be a plugin that merely relies on the host application for presenting the binary data (a good solution, at least on paper IMO).

The basic way a svn repo works is that you have a server process which handles the tracking and primary storage of all differences. Then you have a client process on your working machine which runs always and is hooked into context menus etc (or uses command line). You make a local empty folder and then tag it as an SVN folder by "checking out" a version from a repo on the server. From that point on, you can edit them as you like, but you must use the svn client to move copy or delete the file(s) on the file system. If you add any new files to the local SVN folder, you must then tag them to be tracked. All of this happens locally and the repo only gets updated with any revisions when you manually "commit" back to the repo. Your local copy is a single version and you need to communicate back to the SVN server to revert a file.

All of this is slow compared to no SVN, even for text files, especially if you are checking out a big project. The projects I used SVN (past tense) on were source code based mostly, with 20-30 thousand small files and a full checkout required a coffee break. I suspect that was more due to throughput overhead from so many small files and fewer larger binary files of the same storage size would have been quicker.

GIT works slightly differently I think.

Answer 4

I have using git for my Illustrator and InDesign projects. I have to admit that it's not easy to manage designs that way. Here some tips I wish could help you:

• use straight branch to commit backups of your design;
• try to extract your variables and text data into XML: it works for me in Illustrator design with several languages text translation;
• don't create forks for different design's versions (I used to think that way and ended with several unmergeable and uncomparable publications);
• use external app like WinMerge to copy-paste and compare texts from InDesign/Illustrator, it is a bit against the SVN ideology but it is closer to typos correction and quick comparing publication content versions without having to export texts;
• reconsider the way you use to store your designs: external links and libraries (of colors, symbols etc) is better than one large file.

Answer 5

Just be careful with SVN, I would learn git. It's better with huge file sizes, but still accomplishes subversion control/management. Just more lightweight.

Answer 6

Most versioning systems are designed to handle non-binary file formats. In other words, text files.

They're lightweight, easy to fork and branch and merge and keep track of incremental changes.

Systems like SVN and GIT aren't design to handle PSD files. These are gigantic files and not easily comparable from one version to the next and impossible to 'merge' and fork and the like.

Some may allow binary files--I believe SVN does, but in my experience, it doesn't try to version them. Instead it just swaps out the latest version. So of limited use there.

In addition, if you get in the hang of the version control model of working, you'll learn to check in frequently. This is great for code, but will soon bloat your repository to unmanageable sizes if you're checking in versions of 100mb PSD files every 20 minutes.

Due to a lack of branching and the like, it means you will still likely be doing a lot of that manually, having multiple copies of slightly tweaked files. This, alas, means even more large files that need to be stored so another strike against using version control.

As such, for heavy binary files, you'll want to keep the outside of a version control system such as this and look into DAM (Digital Asset Management) tools.

Alas, there aren't many version control systems designed specifically for heavy documents. Sharepoint is one, but it's clumsy, hardly automated, and rarely set up to handle files the size of PSDs.

The most likely alternative is Adobe's own Version Cue which, I believe, has been turned into the 'Adobe Drive' product:

http://www.adobe.com/products/adobedrive.html