🔒 Locked

Artists and (distributed) version control

Started by mvBarracuda Dec 7, 2010 at 4:04 AM 10 replies 8.7k views

Original Post

Dec 7, 2010 at 4:04 AM

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]

samoth

Dec 7, 2010 at 5:23 AM

I would not use distributed version control in this case. Version control plus artists is generally a bad combination, and you will probably want to keep as much as central control about it as you can.

All version control software assumes that it is trivial or at least very easy to merge changes in an automated or semi-automated way. And, this is true 99% of the time for "text" files (source code etc.). However, it is not true 99% of the time for "art" file (images, sounds etc.).

Different version control systems have different more or less poor excuses (such as "version control is not intended to replace team communication"), but if one is being honest, the bottom line is simply that version control doesn't work for anything but text files. Everything else is usually an epic failure.

The advantage of a centralized system such as Subversion over a distributed one in this case is that you can mark all your art files with the svn:needs-lock property, which will require an artist to lock a file before being able to modify it. There is exactly one authority (the server) that knows whether a given file is in work at a given time. Which, in my opinion, is a huge benefit.
This will somewhat hinder your artists because one cannot work on one file while someone else is holding a lock, but then again this is exactly what you want in that case.

mvBarracuda

Dec 7, 2010 at 5:56 AM

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]

mvBarracuda

Dec 17, 2010 at 3:10 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

flodihn

Dec 17, 2010 at 3:58 PM

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.

21st Century Moose

Jan 18, 2011 at 11:50 PM

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.

LorenzoGatti

Jan 20, 2011 at 9:51 AM

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.

doesnotcompute

Jan 21, 2011 at 12:53 AM

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.

^ *rolls eyes*

To the OP, I would try to keep things as simple as possible for artists. I would prefer Subversion or Perforce to Git/Mercurial. I've been told that Mercurial isn't well suited to handling large binary files, you might keep that in mind when making a decision.

Hodgman

Jan 21, 2011 at 1:04 AM

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.

mvBarracuda

Jan 22, 2011 at 7:34 AM

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.

blewisjr

Jan 25, 2011 at 12:16 AM

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.

I touched on this topic a bit in my recent version control blog post here on the site. The main issue with artists and DVCS is the fact that art are binary assets. You can not safely merge binary assets. The advantage Subversion has in this respect is that you can Lock a binary file when you check it out so no one else can modify it thus no chance exists to have to attempt to merge the file. In DVCS everyone has a full copy of the repository on their local drive so you can damn well guarantee that you are going to have to merge a lot. Git technically has a way around this with the .gitattributes file where you can make a file as binary so that the vcs does not try to merge it however, when you do commits and merges you will see a lot of conflicts for the binary files and by skipping past it git will just replace the whole binary file with the new one. The issue with this method is if two artists modify a file one will be overwritten. IMHO for you project your best bet would be to stick with SVN and if you want have your developers use the git svn command to interoperate with subversion or just stick with subversion.

mvBarracuda

Jan 25, 2011 at 3:20 AM

Thanks for the insight blewisjr :-)

Some of our programmers already use git-svn for the project. We might go for a split approach:
* Code and ingame assets (rendered graphics) reside in a dvcs (git or hg)
* Raw assets (3d models, textures) still reside in SVN

Seahorse1999

Jan 30, 2011 at 7:52 PM

The split approach of having art and code in separate repositories makes it troublesome to revert back to a specific revision at a certain time since you would have to figure out the matching revision in code and art assets you need backtrack to. This is especially true, if you use the "bisect" feature (in git and other vcs) which lets you narrow down an introduced bug but the feature depends on the ability to go backwards to multiple states.

I think the best way to deal with revision control where artists are involved is to simply use SVN for everything and then let your programmers use git-svn or whatever for their distributed needs.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.