This seems to be a novel idea.
Version control has two main aspects:
- Strategic – release builds for bug fixes and formal testing
- Tactical – for development
Typically these two needs conflict. Developers that are refactoring frequently don’t check in there changes until they are finished.
This means that one step too far and you have a lot of rework. In addition it is hard to pass a changeset to another developer/machine without compromising the Strategic version control. This may only be an experiment to identify the shape of future work.
Typically these have been solved by having branches in the vcs. However branching is rather expensive.
In a corporate environment you can have a standardised system imposed due to its provision of work item tracking.
You would not want developers checkin in lots of small changes to the strategic branch – just to back them out later.
A neater solution is to use two distinct systems. Keep the corporate vcs for the strategic use (integration testing, structured builds, work item tracking) but allow the devs to have local version control using a distributed version control system such as Mercurial/Hg.
This allows the developer to check in every time that the local code compiles successfully. It allows you to go back that 5 mins rather than spend that hour redoing your work.
Combined with a suitable suit of unit tests this gives a greater degree of freedom to experiment. In addition you can pass these tactical version control changesets between developers or machines. (How do you take tfs away with you so that you could develop on a plane?).
Developer Rants 