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.
Answer
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).
Attribution
Source : Link , Question Author : Todd Price , Answer Author : gbjbaanb
