It would be really awesome if there was a source control/versioning system that integrated with a text editor so that every change you made was persisted as a new version - you'd never even need to save let alone check in your changes. Infinite-level undo would always be available even across power failures.
This version-control system would have to be multi-headed so that your changes didn't break the version of the product that other people were using or working on until they were ready and tested.
Furthermore, I think this version-control system would be extra awesome if (in the background, or on a remote machine) it rebuilt your program and ran tests on it every time you made a change, so that you were notified of bugs as soon as possible after they occurred.
Obviously there wouldn't be time to build after every keystroke so you'd have to assign a priority to the builds - perhaps the "Save" command could be repurposed to make the current state higher priority, states you mark as "this should be good" are higher priority still and states marked as "this has been reviewed" are marked higher still. If a bug does turn up the system can go back and do a binary search on earlier versions to track down exactly when it was introduced.
There could be a database of all the changes, and another database holding all of the intermediates:
- particular versions of particular files
- built executable files
- intermediate build files
This should allow incremental building and testing to happen pretty quickly (especially if the system knows which changes can affect which executables and which testcases), as long as "rebuild the world" files like compilers and global header files aren't modified.
The system could keep track of which files affect which build steps by watching which files are accessed during a build and keeping this information in the "intermediates" database too.
To eliminate false-positive and false-negative test results due to a dirty machine state, a refinement of the system could run all the tests on a virtual machine, the state of which is reset after each test. This could be done by storing diffs from one virtual machine image to another in the intermediates database. The system could then either build VM images from these diffs (and store them as intermediates) before the tests start or have the VM software choose the right bits dynamically as particular virtual disk sectors are requested (whichever is faster - probably some combination of the two techniques).
[...] This post elaborates on some database organization ideas that I mentioned in passing in Foundry. [...]