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
|