>As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the

>As an example of an inefficiency: Most popular testing frameworks are oblivious to code changes. No matter what you actually changed, the default is to run the entire test suite from beginning to end, which is of course rather inefficient. But to support the kind of seamless develop/build/test cycle that I sketched out, you will want to have exactly that incrementality. That's a job for the testsuite then, I don't want my version control system to require language specific knowledge. It is also a very hard problem if you want to do it 100% correct. Impossible I would say. >It's certainly related to Git, because if you have a live, shared codebase where you don't "commit and push" but rather just edit code that's seamlessly uploaded to the cloud, then the traditionally "commit-push-build-test" workflow loses its meaning. If your editing is "live", it follows that your build/test cycle should also be. I really don't understand how that could work or why you even want it in the first place. It sounds like a nightmare to me. I want to be able to make some local changes, stage them, maybe commit and rebase and finally review and push. For very simple documents live editing works great, but for bigger ones it sucks. I would love to see documents move to the git workflow. Imagine a Word document or an Excel table with an automatically generated version history table from commits, that would be great.