Revision control for games

Engines and Middleware Programming

Started by Hodgman August 14, 2014 02:02 AM

3 comments, last by Mataway 9 years, 8 months ago

52,717

Author

August 14, 2014 02:02 AM

I'm trying to figure out a solution for my company to use, regarding revision control. There doesn't seem to be a good solution out of the box for me...

My requirements seem to be--
Artists / content: Want to use dropbox. Don't care about commits and updates and merges. Just want to save files in a folder. No interruptions to workflow. Check-ins and check-outs must be asynchronous and not cause any interruption, where they're stuck waiting for a check-in to complete before they can continue working. Also need to allow partial check-outs.
Programmers: Want to use Git. Nuff said.
Contractors / outsourcing: Need to be able to work off-site. Require ability to create regional mirrors.
IT: simple to host, configurable network ports, etc...
Management: need branching and tagging.
Continuous integration: No one is allowed to check-in/commit changes to the master/trunk except the automated integration PC. Every check-in is instead queued (in git, this would mean pushing to a temporary remote branch). An integration PC pops items from the queue, and builds and tests them, before being pushed through to the main branch (or not, if they fail). This ensures that the main branch is always stable and you never have to deal with broken builds, memory leaks, etc...

As far as I know, there's nothing that just does all this out of the box. I'm happy to build the CI system, as they usually require a lot of customization anyway, but I was hoping there would be an off-the-shelf version control system...

The first simplification is to accept that maybe code and content will exist in two different repositories. Once I accept that, then I can say, ok programmers get to use Git, and artists can use something else.

Dropbox: Yes for simplicity and asynchronicity, but no for branching/tagging/queued-CI (it's also scary that we don't have an on-site copy of every past version of every file).
Subversion: Queued-CI is an issue because it requires lightweight branching. Users will work in their own branch (I'll call it "workspace") and periodically merge from trunk->workspace. This is too complex for non-technical staff... unless I make a new client for them to use that hides this operation!
Subversion with a new/custom dropbox style assistant: Almost feasible -- the merge process requires network access (the required data can't be pre-downloaded prior to a merge), so it's an extreme interruption. If I could pre-download all the data required for the merge asynchronously, and then perform the merge very quickly, then it would be feasible. Also, check-ins cannot be done asynchronously, and regional mirroring only accelerates read access (write access is not sped up at all).
Perforce: Feasible, but is extremely complex when compared to dropbox! Also, not capable of an asynchronous workflow like dropbox -- artists have their day interrupted by waiting for network operations to complete... Regional proxying also has some issues.
Git: Not feasible for art files, as every user must store the full history (which may be terabytes).
Extended git: git-fat / git-media / git-annex / etc -- feasible, except that it's too complex for non-technical staff.
Extended git with a new/custom dropbox style assistant: Feasible!

But at this point, if I'm setting up git to not actually manage the files, but instead just palm them off to an rsync-based replication system, and have to make a custom dropbox-esque client to hide git's complexity... Maybe I should ditch the git part and just keep the extensions/custom parts?

I'm seriously considering making a new, very simple, lightweight version-control system, based around the concepts in git-fat, using an rsync server and a dropbox-esque custom client!

I don't really have a question here... just thinking out loud about building this new system...

What version control system do you use for your game projects?

Does anyone one else have to manage many gigabytes of game assets?

Does anyone else use a CI server?

. 22 Racing Series .

Nypyren

12,313

August 14, 2014 06:18 AM

It's a tough problem. The core difficulty in my mind is that the software and assets are usually coupled in such a way that the game is unstable if you don't have them both tracked by the same VCS. In many cases, keeping the game stable requires changing code and data at the same time. Having a single commit in VCS is ideal for making sure that each revision of the game is stable.

In order to do their work, everyone on the team needs the ability to run the game to test their changes. (Or do they? Maybe this is not a requirement for your workflow?) This means they need a stable starting point. A particular LKG ("last known good") commit tagged by the CI after it performs a smoke test is one end of the spectrum. The honor system (i.e. distributed-user-performed-smoke-tests) is the other end. I've used all points of the spectrum, and surprisingly the honor system is MUCH more efficient than CI-tagged LKG as long as everyone on the team is actually testing their stuff before pushing it.

(I've seen teams that have no such discipline, and there's generally no saving those kinds of teams regardless of how you deal with assets in VCS.)

If you take assets *completely* out of VCS, you lose your ability to guarantee that a full LKG exists at all. If you do a cross-repo link (such as a submodule or some equivalent) you get into a huge confusing mess of trying to remember when to update the link, what to do with it during a merge, etc.

If you periodically commit assets from Dropbox into VCS, when should that occur? It doesn't seem to me like you can automate this; You have to let the artists decide when their work is ready to be added or updated in the build. If you take snapshots at midnight when everyone's at home sleeping, you might snapshot someone's half-finished work that they were going to finish in the morning, or interrupt someone working in a different time zone (especially if you've outsourced QA or localization).

So if you're committing to VCS anyway, you're back to square one - artists working on assets until they're satisfied with them, then committing and pushing them when they're ready.

The only problem in my mind is the repo bloat. Otherwise, I think that training artists to accept VCS is a necessary evil.

(For this next part, I'm just going to brainstorm wildly - and be sure to keep in mind that I haven't researched how any of the git-media or similar extensions operate - perhaps I'm going to describe exactly what one of them already does...)

Perhaps the solution is to attack the repo bloat itself and leave everything else the same. My observation is this: It's critical to have a long history of code changes, but for assets you only really need enough assets to run a handful of recent revisions of the game that you care about.

It seems like you could write a tool which periodically forks the repo, but rewrites the entire git history as it does it, removing all assets older than the point at which you care (or replace them with some kind of placeholder representation such as a zero-byte file). It's got the benefit of preserving code history, and the bloat-reduction benefits that a "start a new repo with the existing working tree files" has. And since commits in git repos are immutable, it doesn't matter how long it takes an automated process to do this.

Zimans

237

August 14, 2014 01:05 PM

Just speaking out loud here, not from experience. For reference where I work we use SVN for all of our projects, with the exception of kernel/u-boot work which is kept in git and patches stored in SVN.

I am a programmer, my wife is a graphic designer. I love revision control. She hates it.

What about having a system that autonomously monitors the live drop box folder. As files are changed / added / removed it keeps a secondary git repo ( separate from your code repo ) up to date. With the right tools on the server you can download a snapshot of all assets a any point in time without having to clone a terabyte of history, but the history is still ( mostly ) there. You won't get perfect history ( for example if a file is renamed ) and you run the possibility that a file is updated twice before your local copy is synced so you miss the intermediate. Maybe drop box has API's that would give you this information.

--Z

SmkViper

5,396

August 14, 2014 03:41 PM

I'm most familiar with using Perforce professionally, and we have our artists use it as well. IMHO everything should be version-controlled. Sure, you can't (easily) diff a texture or a model, but sometimes being able to roll back to a previous version of an asset or to be able to compare the two is invaluable. We just have Perforce set up so that binary files (like images and models) have exclusive checkout, which prevents the problem of trying to "merge" two people's changes with a non-text-file-format.

And that's not even getting into the risk of people bashing each other's work because they (accidentally, of course!) drop an old file over someone else's newer one. Or if they try to (accidentally) work on the same file at the same time.

Mataway

101

August 14, 2014 07:17 PM

*a wild Perforce shill appears*

FWIW I can think we can hit most of your requirements:

Artists / content: Want to use dropbox. Don't care about commits and updates and merges. Just want to save files in a folder. No interruptions to workflow. Check-ins and check-outs must be asynchronous and not cause any interruption, where they're stuck waiting for a check-in to complete before they can continue working. Also need to allow partial check-outs.

We have plugins for Maya, Max, and Photoshop so that they don't have to think much about the Perforce bits. I've started writing an open source Dropbox-like client, but it's only for the Mac. We have a different one for Windows running around the office; if it would be useful I'll see if I can get the author to let me release the source. Here's the source for mine: https://swarm.workshop.perforce.com/projects/matt-attaway-pulse It's far from perfect (what's error handling?) but it might be useful.

Programmers: Want to use Git. Nuff said.

You can use Git with Perforce now. It's very civilized.

Contractors / outsourcing: Need to be able to work off-site. Require ability to create regional mirrors.

Our replication has become much more sane the past couple releases. Or use Git.

IT: simple to host, configurable network ports, etc...

We're fairly reasonable in this regard. We have packages for all of the server side bits.

Management: need branching and tagging.

Goes without saying. =) The one nice thing is that branches in Git and Perforce can be kept in sync; merges in one turn into merges in the other.

Continuous integration: No one is allowed to check-in/commit changes to the master/trunk except the automated integration PC. Every check-in is instead queued (in git, this would mean pushing to a temporary remote branch). An integration PC pops items from the queue, and builds and tests them, before being pushed through to the main branch (or not, if they fail). This ensures that the main branch is always stable and you never have to deal with broken builds, memory leaks, etc...

Our code review tool Swarm makes this workflow possible using either Git or Perforce. This is exactly how we work in-house. http://www.perforce.com/swarm

It's all free to use up to 20 users/workspaces, with full support if you want to play with it.

Revision control for games

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Revision control for games

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines