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

Göran Krampe goran at krampe.se
Mon Jan 30 08:01:39 UTC 2012


On 01/30/2012 07:45 AM, Hans-Martin Mosner wrote:
> 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.

Code changes is one thing you probably want to *control* (which is why I 
wrote "in some controlled fashion") but some examples of stuff you 
really would like to get "immediately" are:

- Developer X is modifying "your" code. No, not committed yet - but 
perhaps you should talk to X :)

- Visual queue/notification that developer X just managed to break your 
unit tests

- Developer X is right now writing new code that references classes that 
you in turn have modified in your uncommitted code... or sending 
messages whose implementations you in turn have modified in your 
uncommitted code.

...and so on, there are numerous "tell tales" that there will be 
interesting issues down the road - and these signals could be exposed to 
the developers in various ways. Open your mind - it is not all about 
sharing commits of code :)

regards, Göran


More information about the Squeak-dev mailing list