My first post here. On a casual search, I didn’t notice this specific question being asked, so here goes.
At work (Adobe), we use Perforce for all of our source control needs. I like it a lot. At home, I use Subversion for source code management.
My inquiry though, relates to the domain of a content development pipeline, which includes both traditional source code management, but also content assets management. At an abstract level, the objectives of both are the same, but not exactly. For one thing, the intended audience/user is different, where with code source control you are typically (hopefully?!) dealing with professional programmers. People who understand how to manage sandboxes (branches), do proper merges/integrations, etc. etc.
However, for asset versioning management of a content pipeline, I’m imagining a simpler method for artists to keep sync’ed up and to publish changes to be desirable.
So I was hoping to just get feedback on what tools and approaches people are using in their own team asset management that are working well (or even, what was tried and didn’t work well).
I understand that, using Maya as an example (the app I have experience with), the artist is a consumer of both code (MEL, Python, config scripts, etc.) as well as both consumer and producer of content.
I like Tortoise the best since its so simple to use.
But I can imagine in a large team, it could get really slow.
Perforce works solidly, but I’ve found working with it to be a bitch as an artist.
I always dislike having to do anything in its UI.
Dropbox works well in smaller remote teams. Its stupidly simple.
Perhaps tortoise with some sort of scheduled auto-sync would be the ideal combo. But artist do need to be aware how the locking of files works there. Locking of assets is more obvious in perforce.
You could use svn and use a python wrapper with the pysvn module and either override the current save script with a custom one or have a built in menu or shelf button which just calls the appropriate svn calls via python. Now the artist doesn’t need to worry about using svn on the save side. From the load side, I’d say to do the same with a custom open/load scene override or menu/shelf button.
Perforce in every company I’ve worked in, with some alienbrain for concept art or other non-engine related assets.
I love the idea of dropbox and always being in sync, but I also love the idea of not breaking the whole team with a single bad checkin. I’m sure there’s a solution there somewhere.
We actually just went through a round of meetings to discuss source control, so I have some feedback from the art teams here that I can share.
We use Alienbrain for art assets and art tools (python/MEL). It’s fantastic for that, but all (and I mean every single one) of the programmers hate it. We’ve historically used CVS for code, but have been in the process of switching in the past few months to SVN.
Things that are seen as plusses for Alienbrain from the artist view:
File previews
Emailing links to file locations
Seeing both server and local files in one place so there’s no confusion about what files you have or don’t have
The built-in sign-off workflow (speeds up iteration and approvals)
Things that artists complain about with CVS & SVN:
No previews on PSDs or Maya files
Check-outs can be done to any location on the disk, so the artist is never clear where files actually “live”
Can’t see server files without updating
Too easy to overwrite files and lose work
Programmers often will help an artist to “fix” a bug on the artist’s dev machine and end up applying sticky tags or otherwise messing up the local repository so that things don’t update properly
Alienbrain sounds like a very interesting package for non-code asset management. The pricing is not trivial, but doesn’t seem out of reach for mid-to-large enterprises.
I’m guessing an objective of many shops who don’t want to or can’t afford such a solution may be building something with similar objective on their own. There was an interesting chapter in the book “Body Language” by Adam Sidwell, who is/was a TD at Weta Digital, called “Implementing a Character Pipeline: Pipeline in a Box”, that described a home-grown system basically built in MEL and internal to Maya. Anyway, an interesting read, and it got me thinking about how one might expand upon those ideas using Python.
In general, I think content creators should be provided with the means to collaborate in a way that is both effective and friendly to them, and the same for coders. It seems like imposing a single approach on both is not optimal.
For coders, I think any of the major modern SCMs can work. Perforce is really very good in my experience, and I like the fact that it doesn’t have all of those “dot” (hidden, e.g. .svn/) folders all over the place, since all file state information outside of your local revisions is tracked in the central repository/database. I’d like to spend some time with a different class of SCM that have become popular lately that are supposed to be targeted more toward broadly distributed team development such as git, bazaar. From the standpoint of SCM for coders vs. version management for content assets though, I have a feeling there won’t be some huge design approach difference compared to say Subversion that would make them more effective for content management.
One thing I think people in general have failed to consider is how, with so many games being developed post-launch, our content source control practices are going to have to change. Anyone who works on an MMO understands this (or should…). Right now, branching source content is nearly impossible due to hardware constraints. It would be a nightmare. But it is sort of necessary if you wanted true branch integrity.
I don’t think anyone does this, and likely won’t for a while, because it is just easier to do things by hand than figure out how to really solve this problem. But as more and more companies of various sizes are moving into continuously developed games, I think we’ll see some solutions in this area (hopefully using existing tools).
And Thomas, while I agree content creators and coders may want to collaborate differently, it is the ‘live game support’ scenario that makes it an even more difficult problem to solve. Ideally you want everything in branches and on the same version control server. Otherwise trying to figure out what a ‘build’ of your game is becomes technically very difficult and perhaps conceptually impossible to know with certainty (and how much uncertainty are you willing to permit?).
[QUOTE=Rob Galanakis;11796]Ideally you want everything in branches and on the same version control server. Otherwise trying to figure out what a ‘build’ of your game is becomes technically very difficult and perhaps conceptually impossible to know with certainty (and how much uncertainty are you willing to permit?).[/QUOTE]
That’s a very good point, Rob. At the point of assembly of the final product, everything has to be in sync. A single repository would make that a lot easier. -Tom