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

Hans-Martin Mosner hmm at heeg.de
Mon Jan 30 06:45:54 UTC 2012


Am 30.01.2012 00:43, schrieb Göran Krampe:
> 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.
Absolutely! Recording developer intent such as refactorings etc. would be a game-changer that has the potential to
provide much better automatic merge support.
>
> - 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.
>
 Real-time collaboration in the sense of getting code updates from other developers immediatedly is probably not very
helpful, as it would distract a lot. However, support for frequent integration combined with fine granularity goes a
long way. For example, in the project I'm currently working on (using VA Smalltalk and ENVY) we have two-dimensional
cutting of packages: on one axis, there are the different components of the object model (it's a contract management
software, these components are mostly different contract clauses). The other axis is along domain model / GUI /
persistency. This other axis also defines configuration maps, so it is possible to load just the domain model and
persistency stuff to create the runtime image doing the batch processing, or just domain model and GUI for a stand-alone
app.
Due to the fine granularity, the risk of two developers working on the same package is pretty low, and in such cases
collaboration using pair programming is often more productive.

Cheers,
Hans-Martin


More information about the Squeak-dev mailing list