I hope that this thread fits in here. It's not software engineering related, but rather a project management topic. But as there are a couple of project management threads in here, I figured that this might be the right place to post in.

Anyway, 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 :-)

[Edited by - mvBarracuda on December 7, 2010 5:34:32 PM]

Thanks for your insight samoth, that makes sense indeed :-)

This said: we could simply continue to use Subversion for our media branch. The media branch basically contains source versions of all assets (textures, 3d models, uncompressed and therefore lossless versions of the sounds/music). You can take a look at the media branch here: PARPG branches/media

However, if we move to Hg or Git for the programming department, the non-source versions of our assets (rendered sprites of 3d models, compressed sounds/music) would have to reside in the same repository. Otherwise keeping code and non-source assets in sync would be a nightmare I guess. It's a bit hard to explain in theory, so it might be easier by taking a look into our current trunk: PARPG trunk/game

As you can see: the actual game code resides in trunk/game/scripts, while the graphical assets that are needed to run the game reside in trunk/game/objects.

I don't see an easy way to decouple version control of our Python code from the assets in trunk/game/objects. So programmers and artists would either have to use the same version control software, or you would have to have a manager on the team who takes care of transfering the files that the artists commited into your SVN repo to the Hg/Git repo that the programming department is using.

Any idea how this could be addressed? Maybe using some kind of tool like Sparkleshare would help (once it has become more mature and is actually cross platform)? This way the artists could actually work with a DVCS without having to know about the nitty gritty details. I remember that Sparkleshare is aiming for some kind of Github integration in the long run.

Anyway, more feedback appreciated.

[Edited by - mvBarracuda on December 7, 2010 6:56:36 AM]

Looks like this thread won't get more replies for the time being.

I've posted pretty much the same question at stackoverflow as this thread didn't get much feedback. Some good suggestions where brought up there. We'll switch to distributed version control down the line, but we will try to ease the process by providing cheat sheets for each development department. This way they can easily look up how to take care of the usual tasks that fall into their department.

For anyone interested in the details, check out the other answers at StackOverflow: Artists and (distributed) version control

I am using http://www.dropbox.com/ to share files with non technical members in the team.
Its just as easy as copying/deleting files from a normal folder on your computer.

My current project uses SVN and the artists and other non-coders really don't have much problem with it. A lot of it is down to finding and using an SVN client that lets them do the basic stuff they need (update and commit, more or less) without shoving a load of technical jargon in their faces (or forcing them to the command-line). Get that nailed down and the rest follows naturally enough.

Looks like this thread won't get more replies for the time being.

If you think your artists are too stupid to use a proper DVCS, very little advice is applicable; they are certainly too stupid to use anything else, and stupid enough to make a mess irrespective of software used. I don't think TortoiseGit or SmartGit are much more complex than TortoiseSVN or SmartSVN.

My advice is therefore to upgrade your artists, replacing the actually stupid ones and educating the others; while you are at it, teaching and adopting technologically superior software like Git or Mercurial should be the best choice.

Using distributed version control with assets can be a very bad idea, due to the size of the files. DVCS have to duplicate the revision history across all nodes, so if you've got 10 revisions of a 10mb file, and 10 team-members, then that file is taking up 1gb of combined storage... Even on a high-speed LAN your version control system is going to perform very slowly in those conditions.

Splitting code/assets into two repositories is hardly ideal, but it's doable... I'd use Git for text and Subversion for assets. To help deal with the nightmare of the two repos being out of sync, you can compile the revision/head/tag/whatever from each repo into your builds so you know which code/data a build was made with.

Well, I really wouldn't recommend Subversion for non-text assets either -- compared to paid options like Perforce -- but it's far better than Git.

Thanks for the pointer Hodgman :-)

We actually store the two different asset types at different places in the repository. Ingame assets (that are needed to run the game) reside close to the code in trunk. Raw assets (that are source versions of the ingame assets and aren't needed to run the game) reside in a separate media branch in SVN.

We might move our trunk and code branches to git or hg but stick to SVN for the media branch. Right now the media branch is 250mb in size but it will definately grow as soon as we start to produce new assets for the game.