Hi all!

I held a presentation regarding SCM in general a few weeks back as part of a course and in that presentation I try to end it with a view ahead about what is the Next Step for SCM. So let me go "dreaming" here for a minute. :)

As many in this thread has correctly identified the main "issue" with SCM is that when several developers work on the *same* codebase in parallell it gets hairy, no matter which tool you use. Most open source projects actually do *not* do that, we normally work on smallish *different* packages or just a few people on the same package - so we normally don't get to feel the real *hurt* that a large commercial project often does. At least that is my perception.

Yes, MC and git are great. Darcs is in some respects even greater in this particular area (merging, cherry picking etc). But these tools do not capture what I like to call "developer intent" very good.

git and Darcs etc just manage files, they don't even know what language we are using. Darcs has something in the "right direction" and that is the token replace change, which is a small step towards "smarter change types".

MC knows it is Smalltalk source it is dealing with, but doesn't really use that knowledge as much as it could.

Deltas that I started working with (and came quite far with the help of Matthew Fulmer and a few others) goes a few steps further. A Delta distinguishes developer intent in greater detail than MC and could potentially be "smarter" because of that.

And this is where the general future of SCM lies I think, in two areas:

- Making SCM tools aware of developer intent. If I use RB to do a refactoring for example, why not *record that* and not just record the effects of the recactoring on the source code? If I rename a method in a class, and fix all senders of it, why not record it as a *method rename*? That way, if it is merged into another environment it can be handled much smarter and we could for example fix even more senders.

- Real time collaboration. If we can sit in a shared (in some controlled fashion) development environment in some kind of real time model, then lots of merging and conflicts would just say PUFF and go up in smoke. We are beginning to see this now with the new IDEs running "on the web" because suddenly it gets very natural to experiment in that direction.

regards, Göran

Reply via email to