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

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]http://svn.example.org/graphics/rendered

This instructs Mercurial to make a svn checkout of http://svn.example.org/graphics/rendered 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:

• http://betterexplained.com/articles/a-visual-guide-to-version-control/
• http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

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.