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.

  • How are you structuring your Git repository workflow?
  • Mercurial: Merging one file between branches in one repo
  • How to diff two commits or files on a remote repository with git?
  • How do I keep an svn:external up to date using git-svn?
  • hg equivalant of git revert
  • Undo working copy modifications of one file in 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 🙂

  • What does this git code mean?
  • how to add files/folders to gitignore in intellij GUI?
  • Merge more than 2 branches/heads at once in Git?
  • Git patch - patch does not apply
  • Git alias parameter completion doesn't work in Zsh
  • Git clone fsync input/output error in linux
  • 6 Solutions collect form web for “Can artists realistically cope with (distributed) version control in an open source environment?”

    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.

    With Mercurial, you have the option of letting the artists continue with Subversion, while letting the developers switch to Mercurial and thus enjoy the benefits of distributed revision control.

    The trick is to use a Subversion subrepository in Mercurial. Mercurial lets you nest repositories: Mercurial 1.7 has support for Mercurial and Subversion subrepositories, Mercurial 1.8 will have support for Git subrepositories.

    You control a subrepo via a file called .hgsub. In your case you would add something like this to the file:

    graphics/rendered = [svn]

    This instructs Mercurial to make a svn checkout of and to store the checkout as graphics/rendered in your Mercurial working copy. In other words, the format of the .hgsub file is

    mount-point = [type]source-URL

    You make the first checkout yourself, add the .hgsub file and make a Mercurial commit. At that point, Mercurial will take note of the precise Subversion revision that is checked out in your subrepo. This revision number is stored in .hgsubstate, which is an extra file tracked by Mercurial.

    When another developer makes a clone of the Mercurial repository, Mercurial will notice the .hgsub and .hgsubstate files, and use them to recreate the Subversion checkout you committed.

    The advantages of this solution are:

    1. the artists can continue working with Subversion. Here I’m simplifying things a bit by assuming that they can work with their graphics files in isolation without cloning the outer Mercurial repository. Even if that is not true, then they can still do the majority of their work using Subversion and only do hg pull --update once in a while to get the latest Mercurial changes.

    2. developers wont have to download all revisions of all graphics files. This is normally a show-stopper for (any) distributed revision control system when talking about large binary files.

      The problem is that with centralized revision control, it is only the server that needs to store all revisions of a given file, but with distributed revision control every developer stored every version.

      Externalizing the binary assets into a Subversion subrepo side-steps this issue.

    Mercurial is all about revision control and about giving you consistent snapshots of the project. Mercurial will therefore only checkout things that were explicitly committed. This means that the developers will have to regularly pull in new Subversion revisions:

    $ cd graphics/rendered
    $ svn update
    $ cd ../..
    $ # test new graphics!
    $ hg commit -m 'Updated graphics'

    The Mercurial commit is committing the new Subversion revision number in the .hgsubstate file — Mercurial will take care of inserting the number in the file, the developers just have to commit it. This way, each Mercurial changeset will reference a particular Subversion revision via the .hgsubstate file, and so you can recreate any past state (consisting of source code and graphics) accurately.

    The following are good visual introduction to version control and Mercurial.

    Try to see, if it helps in making it easier to understand. I would find it very difficult to use something, which I can not wrap around in my head.

    So here are few good visual introductions:

    Git exposes a more detailed model, which is liked by many programmers. Mercurial provides a more clean and smaller subset of concepts to deal with. I believe Mercurial will be more suitable for your purpose.

    We have Artists working on games with GIT.
    For us the SmartGIT client is essential.

    It also comes in SVN flavor.


    i might be a bit late to the party (and hopefully not off topic), but in your original post you mentioned:

    “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

    if you are really interested in Perforce you might be interested to know:

    “If you develop software that is
    licensed or otherwise distributed
    exclusively under an Open Source
    license, you may be eligible to obtain
    a Perforce license free of charge.
    This includes upgrades but does not
    include Technical Support.” —

    It sounds to me like you’re having a hard enough time getting the artists to use SVN and pushing DVCS on them would be a losing battle. Perhaps there’s a way to update the DVCS with SVN checkins so that the DVCS can stay up-to-date with SVN?

    Regarding adoption of SVN, I think it really catches on for people with they see it as something they need (or can’t live without), rather than something ‘the man’ is forcing them to do. If they could see how they can benefit from the tool (ie, rolling back to previous revisions, etc), they may be more eager to adopt it. However, I don’t know if SVN can benefit an artist the way it does a programmer.

    As a programmer who’s developed both with and without VCS, I can honestly say the VCS world is a much better place, and I will never go back to a world without.

    Git Baby is a git and github fan, let's start git clone.