Some user experience with SubVersion... We've used Subversion on several feature films (Free Jimmy, Kurt Turns Evil and another one currently in production). Integration with Maya is done through Mel scripts that pass system commands to the SVN client, and commiting is integrated with the save and save as commands, so that every time the user saves a version controlled file, a promptDialog pops up, asking if he or she wants to commit.
Our SubVersion setup does not use locking. If you have two artists working on the same file at the same time, you have a production management problem, not an SVN problem. If several people do work on the same asset, you most definitively want to have the revision history for both of them, and then you either let the two artists in question fight about whose version wins, or merge the differing work manually in Maya. We have a Python script running all the time that tracks what files are open on every machine in the building, and warns the second person attempting to open a file, or an asset (if someone is working on the model file, you get a warning when opening the UV file, etc). I think this is a better solution, as it also covers files that are not SubVersioned (you dont want to have people save over those either), and files don't get stuck when Maya crashes. We do not use merging either. I don't see how helpful that could be when dealing with files that may contain hundreds of thousands of lines of text. The Subversion log is stored in a database, so it can be integrated in production management web pages etc without having to make slow SVN log requests all the time. There are several features I want to add to our current setup. Among them... Better integration with our database tracking system. We have strict conventions for what files are associated with each asset, animation scene etc. Whenever an artist creates a file that is part of the asset workflow, that is logged in the database, and should also be automatically added and commited to SubVersion. A really user friendly GUI for performing the most essential SVN operations (not even TortoiseSVN is *that *user friendly from an artist's point of view). This would automate most processes, like adding, renaming, moving files; reverting/saving out revisions, etc. Automatic updating of assets when working with local checkouts. This could possibly be running in a thread at regular intervals, and then when the artist opens a file, an additional script makes sure the file and all its references are up to date. Various working copy repair tools. SubVersion is way to buggy when the working copy resides on a network share. You'll commit a file and everything is dandy, but somehow SubVersion thinks that the commit wasn't made, so it tries to update the working copy, making a total mess as it tries to merge the commit with the last save, or it just flat out refuses to commit. Usually, the workaround is to rename the latest noncommited saved file, update the folder so that Subversion puts the file back, delete that file and then rename the correct saved file back again and commit that. I agree that the way to go is to create something more general that can then be hooked up with Maya, Softimage, Fusion, Nuke etc through Python, and in some way to Adobe software, 3ds max, MS Word etc Here's how its done in Perforce: http://www.perforce.com/perforce/products/plugins-p4gt.html The best would definitively be to make it version control, os and database agnostic, so one can use any combination one would like of Windows, Linux, SubVersion, CVS, Perforce, MySQL, SQLServer and so on. Jo Jurgens Senior TD Qvisten Animation Oslo, Norway --~--~---------~--~----~------------~-------~--~----~ Yours, Maya-Python Club Team. -~----------~----~----~----~------~----~------~--~---
