I've been thinking more and more about a mud engine that is version control aware. Throughout this ramble, I'll talk using git terminology, since that is what I'm most familiar with. The concepts should be applicable to most modern version control systems however.
My idea is that there are two methods to the vcs integration, playerfile saving, and world instancing.
In this ideal world, every (configurable) 10 minutes, a worker would sync all players to disk, then commit the changes with a generated commit message (ex: [autosave] 153 player files). The integration would know exactly which playerfiles have changed, and would be able to add those to the index, and commit that index. (in git, you first add changes to an index, then commit those changes. for hg/bzr, you'd most likely run the commit command and pass in all of the changes files)
The other part of the integration is world saving, and is the more difficult, and more rewarding portion. This would map closer to the actual underlying vcs, and allow a builder to create an instance of the world where any long-lived building would take place (for instance, a brand new zone). You could go into edit mode on the :master clone for quick fixes, but most changes would occur in an instance.
This would result in object keys of the form <key>@<area>:<clone>, to keep the separation. A user would not be in room@zone, they would be in room@zone:master, or room@zone:project_awesome, no code would act on room@zone it would act on room@zone:master, for instance.
Anytime a builder exits out of an OLC, if they've made any changes, they are given the standard save prompt, with one addition: Save and Commit (eg: > Save your changes (Y,N) or Save and Commit (C)?). If they elect to commit, they are given a prompt for a commit message immediately. If they elect to just Save, then the edits will be added to the 'index' (for lack of a better word) until the user manually invokes @commit. This allows them to make a quick edit that isn't really related to the rest of the edits they may be working on. They would also have the ability to view a list of their outstanding edits, and can pop open the OLC menu for a specific object they've edited already, and immediately commit just those changes.
To keep things easier to manage, any edits made that were not committed lock the actual objects that were edited from further edits until the edit is committed or aborted. Since people should be working on their own instances, I think this is a safe compromise. If someone needs to edit something you've edited, they should do it in their own instance.
In this scenario, Builder is the head builder, who is bringing on Newbie, a new builder. Builder creates a new instance (named newbie), and inside of the new instance, creates a new zone and gives full editing rights to Newbie.
Newbie logs on, and the Builder tells her to @goto start@newzone:newbie. Newbie goes there, and begins working on her zone. The first handful of rooms, she commits every single time. Later, she decides she wants to build a dungeon with a boss and everything, and Builder tells her that she doesn't need to commit every single change, but can commit a group of related changes at one time, with one message. Newbie decides this would be ideal for this purpose, so she starts building out her dungeon. She creates the basic layout of the dungeon and gets tired. She logs off and goes to sleep and when she comes back the next day realizes that her edits are still there. She dives back in, finishes up her rooms, creates the boss, runs it through a play-test a bit, makes some edits, then finally commits her outstanding edits (@commit), which prompts her for a message.
After all this, Newbie tells Builder that she's done with her new zone. Builder investigates, discovers that it still has a few changes that need to be made, which Newbie does quickly. Builder signs off on it, and notifies a system administrator that the instance is complete and should be merged.
That night, the system administrator takes the MUD down, merges the newbies instance into the 'master' instance, then deletes the newbies instance and boots the MUD back up.
Fin.