/ by Toni
Orange is not a huge studio, but of course we still need proper technical setup for fluent workflow. By putting the six workstations and a fileserver in place, connected via a gigabit ethernet, the basic infrastructure was built during the first weeks. Pre-production began using a plain shared filesystem, but now as we entered production phase in the sense that scenes are put together for the animatic, we decided to use a versioning system instead.
A major reason is ensuring that no-one ever destroys work by others, which can happen easily with filesystems by simply saving an older version over a newer one made by someone else in the meantime. But our tech-savvy animation director Bassam figured that even advanced features like branching, i.e. making an alternative version of the movie-in-the-making, might be useful later for e.g. testing changes in the main characters.
We chose Subversion (svn), a popular CVS replacement, as it is friendly for basic operations such as renaming files. It will be interesting to see how well it works for blend files and other animation source data, such as large textures,and whether it fits in the way artists work individually and in collaboration.
Version control systems have been mostly made with software development in mind, and are commonly used by programmers, but nothing prevents using them for other kinds of data too. We do have experience of having blend files in cvs and svn repositories from open source
games, like from the Freedroid project where Basse has contributed, and from Soya-using Slune, Balazar and Overdrive (Soya3d can use Blender to open .blend files, so the cvs versions of the games get the models and character animations straight from blends). Everything has worked ok there, so we dared to make this decision..
With almost only binary data, we do not get the informative ‘diffs’, i.e. the information about changes made in a particular commit (save to the repository), that versioning systems give for text based software source files. But the commit messages, i.e. the info that the person who makes a change / adds a new file to the repository must write when committing, do still give info about what has changed where (as long as the guys keep up writing them properly! :)
I’m used to using the command line, but some of the others prefer GUI tools (and me too sometimes). On Linux, we are using both Gnome and KDE Desktop environments. For KDE there seems to be a nice plugin for the Konqueror browser / file manager, called ksvn, that I’ll try. On Gnome Bassam tried one Nautilus script which didn’t seem to work too well (it showed the svn commands also for files that were not in any svn working directory). But eSVN seems ok, so that’ll probably serve Lee who’s used to GUIs and using Gnome now (although eSVN uses qt if of course works in Gnome too).
On the macs, guys are now using a Finder plugin (which is open source) that works nicely for basic operations. For advanced operations, an open source macosx app called svnX seems great: when looking at the log, and selecting some commit/revision, the integrated browser shows that version of the project, and let’s the user open an old version of any file from there. I wonder if that, probably Cocoa-using, svnX tool would be easy to port to GNUStep..
We are still using the file share (samba) for non-versioned files, like reference photo collections, and also for saving rendered animations. The idea is to keep the production folder in the svn repository clean from extra data, but with all the necessary files for rendering, so that we can use Subversion also for synching with the render farm in the U.S. later on.
For the future, it might be interesting to investigate if blend files could be somehow ‘diffable’, although it may be that the range of operations done in 3d modelling and animation can not be captured in that way. Concerning using binary data, Subversion seems better fit than CVS, and reports even using binary diffing so conserving the full history might not take an awful lot of extra space. I haven’t looked how well it is actually able to diff e.g. blend files in this space-preserving sense, nor don’t know if they are suitable for such diffing at all.
So as it is, we seem to have a working solution, and the animatic progresses! *knocked-on-wood*