[Pharo-project] Future of SCM (was Re: [squeak-dev] Re: [Smalltalk for small projects only?)

Göran Krampe goran at krampe.se
Sun Jan 29 18:43:54 EST 2012


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




More information about the Pharo-dev mailing list