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

Ben Coman btc at openInWorld.com
Tue Jan 31 12:46:02 UTC 2012

Göran Krampe wrote:
> 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
While dreaming...
How about the same that whole projects (on say sourceforge) have an 
activity meter, an image can report current activity on individual 
classes & methods (initially to a central server and later P2P) which is 
aggregated from and visible in other participating images.  As well as 
code changes this could include indications of just browsing - which 
would leave 'footprints' so that when you are looking at some method you 
can see that 'Mr Smith' happened to have passed by a few hours ago - and 
in a pane to the right of the method is something like IRC or a 
discussion board where you can say "Hey. Whatchya up to here."

More information about the Squeak-dev mailing list