I've looked hard at other threads similar to this, but still can't find anyone with a good recommendation for a cross-platform (OSX, Windows) team workflow in InDesign that is easy and doesn't require users to work directly off a network share.

Does anyone have any real world experience supporting a check-in / check-out system for InDesign such as this:

  • designer gets latest project files from network share or version control system to OSX
  • designer works on files locally
  • designer commits work back to the network share or version control system
  • editor gets latest project files from network share or version control system to Windows
  • editor works on files locally
  • editor commits work back to the network share or version control system

I'm considering Subversion since there are multiple clients across both platforms. I use SVN for our app dev teams and love it. But would the repository get bloated with nothing but large binary files being committed all the time? Can I disable versioning and just have it keep the last version (no worse than a network share)?

The point is to have a system where people can work locally, not have to worry about overwriting each other's work, and easily get and commit changes.

  • Is Adobe Version Cue (included in Creative Suite) not fitting the bill? – Sven Sep 1 '10 at 16:12
  • Does Adobe have tools to "diff" & merge InDesign documents? – JanC Sep 1 '10 at 16:22
  • Meant to mention this in my post. Version Cue has been documented by many who have used it as a miserable attempt at a solution in this space. See this blog series for example: outsmartcomputers.com/2009/05/… – Todd Price Sep 2 '10 at 16:47
  • Version Cue has been discontinued by Adobe. I've been hoping this would lead to other tools appearing, but so far the market has been quiet. – Martijn Heemels Dec 23 '11 at 23:55

no, SVN cannot store the 'only last version', I think (of all the SCMs I've used) that Visual Source Safe is the only one to have this feature.

SVN handles binaries quite happily, and committing them will only add the diffs to the repo, so its not going to bloat that quickly. It'll still bloat compared to text files though (my experience: putting 1MB dlls in there doesn't bloat it very much at all).

You can de-bloat occasionally by exporting the entire repository, then deleting it, and adding the exported files back in. You lose history (obviously) but you will have just the latest version of the files and a tiny, trim repo afterwards. If you don't care about the history this would work. Just don't use the same repo with files you do care about their history - or dump/filter/load those files to keep it.

SVN handles large repo sizes quite well, I have one with 300,000 revisions and 12Gb in size.

You will have issues with locking, as you cannot merge changes from 2 binary files into 1. So your designers will have to adopt the lock-modify-commit model.

Also, if you have the right setup, you can work with SVN on a webdav share - so the repo appears to the designers as a network share. They copy off the share to local, edit the file, then copy it back and it performs a commit in the background. However, this does not lock the file, so overwrites will occur. Your team may be happy with that limitation though as it means they don't ever have to worry about updating their working copy and still get the benefit of history.

edit: FYI, you can see how large a delta is by looking in the SVN repo directly. SVN stores each revision as a file in a directory called db/revs. With the latest versions, there will be one directory for each 1000 revisions, named with the number. So, assuming you have less than a thousand revisions, there will be a directory called '0', in there will be 1 file per revision. Check something in, and look at the size of that file. That's the delta size (for the entire revision, you can get the size of each individual file inside that, but it requires looking at the file's contents - easier to commit just 1 file in that revision to see).

  • Good thoughts, thanks. I wouldn't go with WebDAV because all it gives us is versioning, which we don't (currently) care about. But I wasn't aware that SVN stores deltas only for commits on binaries. That's potentially good news. – Todd Price Sep 2 '10 at 16:50
  • Thanks for the update! That's extremely helpful as I'd planned to dig in and see the delta sizes myself today. – Todd Price Sep 8 '10 at 12:07

It sounds like Subversion is your most likely answer, however you cannot merge changes in binaries. I believe that Git and Mercurial will suffer from the same problem.

  • Right, binary merges aren't generically possible because the content type isn't known. I suppose one could create a merge for a specific binary type such as InDesign though. Text files themselves are just a special kind of binary where merge algorithms are widely available. – Todd Price Sep 2 '10 at 16:57
  • no, you cannot merge binaries in SVN. With text files you can cherry pick revisions to merge.. that simply would not work (sensibly) with binary files. Instead you get to choose which one to take (ie as a 'merge' would otherwise be a windiff-style merging that takes one file and turns it into another, you might as well take the final result). However, you can diff/merge with known binary types (eg jpg) where the diffs make sense and could be merged. (eg araxis.com/merge/topic_comparing_image_files.html) - see TortoiseIDiff for a less-featured version. – gbjbaanb Sep 8 '10 at 16:14

I may be wrong, but isn't one of the main promises of SVN that it can actually deal with incremental changes in binaries?

Anyways, for a designer I would recommend using Subversion with a client like this one:


  • 1
    This app looks promising. Do you have experience with it personally? – Todd Price Sep 2 '10 at 16:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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