Future of SCM (was Re: [Pharo-project] [squeak-dev] Re: [Smalltalk
for small projects only?)
Göran Krampe
goran at krampe.se
Sun Jan 29 23:43:54 UTC 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 Squeak-dev
mailing list
|