Search code examples
gitopen-sourcemercurialproject-managementdvcs

Can artists realistically cope with (distributed) version control in an open source environment?


Heya, I'm working in the project management department of an open source game. Right now we're using SVN for version control and store code and assets in the same repository. Source versions of assets (models, textures) reside in a separate media branch, while the rendered versions of the assets (we're working on an isometric 2d game, so we actually use rendered 2d images of the 3d models in the game) reside close to the code, as they're needed to be in place to run the game.

Our artists had a hard time to get started with using Subversion and to wrap their head around the concept of version control in general. Right now the project mostly consists of programmers and we're considering to move from SVN to distributed version control to ease working with branches (and the associated merging process) and sending in patches. We haven't made a decision about which DVCS to use yet, but we will most likely end up using either Mercurial or Git.

While distributed version control is great for developers with a technical background, it might seem overly complex and complicated for artist and other prolly less tech savvy devs.

So I'm looking for all kinds of advice how we could ease the version control workflow for artists. Keep in mind that using something like Perforce, regardless of how suited it might be for the job, is not option for a free of charge open source project. So I'm pretty much rather looking for advice, tutorials, project tools that make it easy for artists to wrap their head around distributed version control, especially Hg and/or Git.

Is it even worth going down that route and try to get the artists using distributed version control? We could continue to store the source versions of assets (textures, models) in our existing SVN repository. But we would still have to find a solution for the assets that are needed to run the game, as they should reside close to the code in version control.

There are a bunch of great DVCS guides out there, e.g. the Hginit tutorial. However the ones I've found were all written for programmers. It's great that they can now easily locally commit, use the full potential of branches and merge back their changes without too much hassle. But this might not be beneficial for artists but rather overly complex and scary to them. Do you happen to know a DVCS tutorial that was written for artists as the primary target audience?

We're also using Trac for project management purposes, so if you know of a Trac plugin that is artist friendly, let me know as well :-)


Solution

  • I'm not even sure programmers can realistically cope with distributed version control. For proof, I offer the number of distributed version control questions on Stack Overflow.

    My suggestion would be to give the artists two checklists or cheat sheets. One to commit art work, and one to retrieve art work. These cheat sheets would be specific to your work environment.

    If an artist wants to understand the what of source control, one of the programmers can explain the details.

    It's been my experience that most people want to get their work done, and don't care about the what. They just care about how.