Version control pipeline for small Maya house

#1

I’m sorry to revive a topic that has been talked about, but I wanted to see if there may be new thoughts on this and ones more focused towards my need. I am starting up a small cg animation house and I’m currently working on trying to hammer out a production work flow for us. I have not brought any employees in yet, so I think this is a good stage to come up with a rough pipeline for multi-user use so when they come in I can get them up and running. We are going to be pretty small, around 5-6 artists for the first year and we use Maya as our DCC tool. My background has been in games and I am used to working with Perforce and CVS. I like their checkin/checkout approach and I’m looking for something similar but much more cost effective (free would be great) and something that is pretty light on the tech setup. Any suggestions?

Thank you in advance!
BT

#2

CVS was free the last time I checked, as is its heir SVN.
Not a huge fan of using source/versioning control originally meant for code, but for assets, personally.

If you are happy with that though, again, CVS, SVN (with turtle if you’re on windows) will do fine. There’s git too, but by nature it might not lend itself as easily to what you want, not as easily as the former anyway.

#3

Well in my experience SVN seems to do well with production assets. I have been using SVN for asset version control for almost 2 years now for my own short film and have had no issues, other than permission and ssh keys (our host is a private server so security is very tight). The Aqsis guys had expressed some concern with corruption of binary files however in the end it has proven to be solid, since SVN and CVS are designed for plain text files after all. This includes Blender files and texture maps both of which are binary.

Git on the other hand I have had issues with, a lot of the custom tools and most importantly the development version of Aqsis is on Git. It could just be my own system not configured properly or ssh keys getting mixed up for different code projects.

SVN clients are also plentiful and come in both open source and commercial, so if you want to remain open source there is no shortage of tools and help there.

Setup of an SVN server is not as easy as connecting to one but again there is plenty of help out there to help you along.

#4

It all depends from scale, branching needs and overal size of the live version (and how much of it is binary assets).
SVN can do all of that, and will work fine for a number of teams, just bear in mind that if part of your work philosophy involves branching, or relies on mandatory check-out before check-in (ala perforce or cc), then it will be the wrong tool for the job.

Branching and tagging, while better since a couple versions ago, are still sorely lacking, and there is no reliable way to implement co/ci asset locks the way some pipelines are setup.
It’s also a system that doesn’t really virtualize a file system, nor deal very well with it in many instances, which can be a plus or a bit hurdle depending on preference and needs.

Those things, in general terms, hurt scalability of systems based on SVN for asset management. If you run a small and tight team, and reservation and branching aren’t fundamentals of your design, then it’s a viable solution.

#5

Thank you for your replies guys. Very informative. One question though, I’ve been leaning toward SVN because I’ve found a version of it compiled for the Drobo FS (which we are using as our file server). I am curious though, what do you mean about mandatory checkouts before checkins?

Thanks,
BT

#6

Some systems allow for reserving mechanics, one of which is the mandate to check a file out and workign with it in a branch before it can be checked out, to avoid the classic situation where somebody has a local file that’s out of date, keeps working on it, and then checks it in, even if his check-out of that file was stale.
SVN isn’t the best when it comes to reservation mechanics.

#7

Ahh ok, I gotcha. Thank you for the explanation.

Cheers,
BT

#8

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.