Pixar uses Perforce. Over 1000 users, 12 million ops/day, 40 million changelists, 115 million files, >20 TB data, and accessed by 12,000 cpu renderfarm. If you're dealing with large amounts of binary data it's basically a solved problem and Perforce is the answer. An expensive answer but an answer.
Just curious, what makes you think they don't already use version control prolifically? What opportunity do you see? One studio I'm familiar with has some assets with change history back through to SCCS -- back through RCS, CVS, and P4. These places have long dealt with large groups of people collaborating on shared files that are constantly changing, forking, merging, etc.
I've worked quite a bit in the cgi and 3D graphics side of the industry and at least from what I've seen there the use of version control is lacking to say the least. The de-facto industry standard seems to be a directory full of files with names like scene_latest3_newest_old2.max.
Although it also seems to be more of a cultural issue. There are already pretty good tools from companies like Perforce and Alienbrain, the problem is to convince the artists that there is value in using them. Every time I've suggested it, there has been imitiate pushback and outright rejection from the artists. Even in the places I've seen that use Perforce, most artists seem to see checking in and out as a pointless chore, rather than a vital and helpful part of their workflow
I'm guessing they're working with file formats that can't be diffed or merged. In which case all the version control is doing is just storing the file. Branching, forking or collaboration isn't possible in the way it is with text code.
In that case it really doesn't benefit them at all and is a chore. You'll only get them to use version control if it's hard mandate (good luck) or figure out a way to make it completely transparent to them (something like Time Machine).
I'm sure lots of bigger places do use it. In the world of music, there are studios everywhere that have maybe a dozen staff, making a lot of money and producing a lot of output, where version control is an unheard of concept. No audio production software that I'm aware of has any provision for version control.
I was kindof assuming that it would be the same for mid to smaller sized movie/tv studios as well, but at the same time I wouldn't be surprised to learn that you can get a plugin for Premier or whatever that does it.
I know for a fact that there are many largish advertising agencies out there who have fileservers with hundreds of ProjectName01, ProjectName02 etc style directories.
Why do you think apple brought "Versions" or whatever its called in with lion?
Thanks for clarifying. I agree there are many environments that would benefit from version control but that lack the technical resources to make it happen with existing tech.
Versions (and Time Machine history) are good steps to part of this, in that they are easily available and understandable, but they don't solve the collaboration aspect. How do you diff and merge your local changes into the NEW_final_v2_UPDATED.xls that was emailed to you? I'd summarize the problems as:
- identfying & organizing versions of the same document in ways manageable by normal humans (i.e. not a set of variably-named files spanning email attachments and shared folders, nor a graph of nodes identified by 20-byte hashes, nor a rigid interface to a versioned-file server)
I use Sequoia (http://pro.magix.com/en/sequoia/overview.527.html) and I'm very happy with the 'Save Project Copy' function. When I start a new project, I create a 'history' folder and the project copies go in there, named as project_name-timestamp.VIP. I do that every time I'm a stopping point, much like how I use 'git commit' on a code project.
That doesn't mean there isn't huge room for improvement in this arena. An approach like this (or OSX's versions) doesn't allow you to do anything like 'git diff' to see what's changed from version to version. I can imagine this is a very difficult problem for binary data, however. Also, distributed version control on media production software could allow for multiple users to be editing a project simultaneously.
Unfortunately, I don't really see GitHub being able to help much here. For example, any work done to make ProTools files git-friendly wouldn't also work on Photoshop files. I'd love to be wrong about this, but I suspect seeing version control in media production software would require redesigning the application's file format from the ground up, and would be a task for each software company to do on their own.
Not just movie/music studios. Who could reap huge rewards from great distributed version control? Anyone who collaborates on some computer file regularly.
So everyone. Or at least everyone who works in an office.
My own erstwhile field of small business accounting is all about version control. An enormous amount of energy goes into keeping tabs on which file is most current and ensuring that work isn't done in a non-current file.
Same thing for anyone who regularly collaborates on documents or spreadsheets or images: lawyers, advertisers, my friend the outdoor school counselor, journalists, etc.
The state of the art here isn't very good. For all the products out there, I'd guess 90% of actual version control happens via emails. Case in point:
A journalist friend of mine is currently attempting a small intra-office coup to switch from Email/Excel to Asana for scheduling and managing the editing process. It is not going well. Email/Excel will probably win.
But the old people won't be around forever. The opportunities to improve on the state of the art are vast. The amount of energy people spend on keeping current could be dramatically reduced.
The movie studios are not so open with software, but almost all of them do use open source software in some way, and most certainly nearly all have developers that use some varying amount of version control.
thingverse is a pretty popular free distribution channel for 3d-printable objects - but there's no way to integrate forks. So people copy an object & improve it, but there's no way to put that fix back into the main line.
Getting these people to use github would be awesome!