automatic commits and updates is such a horrible idea.

developers need a stable base upon which to make changes over time, which they sync up to the trunk when they are prepared to, not when their IDE chooses to.  just b/c tests pass doesn't mean your changes are compatible with my changes.  have you never worked on a project where multiple ppl are changing the same files?  

the goal of CI isn't to automate your entire workflow.  that mindset is a slippery slope towards code generation and robots programming.

I don't like the idea of a passing test updating VC or kicking off CI.  Many times my tests 'pass', but I am not done with either the test or code under test.  I could have logic that is mid cycle and checking everything in could foobar the next guy trying to use my code.

I see your point, but I think that check-ins have to be a manual, with intent process.

I'm a little wary of the auto-commit idea - explicit commits are important for lots of reasons, not least of which is identification of atomic changes that need to be integrated to other branches of the code.  

The idea of the working copy being auto-updated is ok for me, but may not work on larger projects that contain multiple solutions, in such a way that for the new working copy to function, I would need new binaries too, and possibly even a database migration script.  Also, if a programmer is spiking on something, then they may throw away changes - integrating too early can be a bad thing then.

That said, I can see scenarios where the idea has merit - perhaps in the beginning stages of the project, where we are growing from nothing to something.  Often, team members have to wait around while someone else works on a core feature.  In that case, perhaps it would be good to get a more rapid integration cycle.  

"The other scenario is when Dev A and Dev B are editing the same block of code, which leads to merge conflicts. In this scenario "CIVCS" wound't be able to not automerge the changes but instead could indicate the merge conflict by putting a "merge confilct" icon in the gutter to the left of the relevant lines of code."

but then i'm forced to resolve the conflict _now_ instead of when i'm ready to (when my code is finished and ready, by my definition of ready, for integration)

disruption and context switches lower productivity substantially, on average.

While this sounds pretty good and reasonable you are asking your development environment to do the equivalent of realizing when you want a beer and walking over to the kitchen to bring you one.

btw: commit on tests pass only works if I write tests first ;-)

I feel the need to chime in here as well. Interesting ideas but like everyone else I think auto-commit is a very bad idea.

The last step of the TDD mantra is refactor. Therefore, if an auto-commit is happening every green step, then you never have an opportunity to refactor your tests/code to support the new test. In addition, I write 10-20 tests between commits because  one commit from my workstation often includes a set of tests that test a specific portion of the project, but just a single test per commit.

Some of your ideas are great though, opening your IDE and it automatically getting the most current revision from SC is a good idea, maybe with an alert window in case you don't want the most recent revisions however.