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 :-)
Downsides of Distributed Version Control Systems: DVCS enables you to clone the repository – this could mean a security issue. Managing non-mergeable files is contrary to the DVCS concept. Working with a lot of binary files requires a huge amount of space, and developers can't do diffs.
DVCS is faster than CVCS because you don't need to communicate with the remote server for each and every command. You do everything locally which gives you the benefit to work faster than CVCS. Working on branches is easy in DVCS.
Version control provides access to the historical versions of a project. This is insurance against computer crashes or data loss. If any mistake is made, you can easily roll back to a previous version. It is also possible to undo specific edits that too without losing the work done in the meanwhile.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With