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

Frank Shearar frank.shearar at gmail.com
Tue Jan 31 13:00:28 UTC 2012

On 31 January 2012 12:46, Ben Coman <btc at openinworld.com> wrote:
> 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."

As long as you can _switch_that_off_!


More information about the Squeak-dev mailing list