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?