Future of SCM (was Re: [Pharo-project] [squeak-dev] Re: [Smalltalk for small projects only?)
Hi all!
I held a presentation regarding SCM in general a few weeks back as part of a course and in that presentation I try to end it with a view ahead about what is the Next Step for SCM. So let me go "dreaming" here for a minute. :)
As many in this thread has correctly identified the main "issue" with SCM is that when several developers work on the *same* codebase in parallell it gets hairy, no matter which tool you use. Most open source projects actually do *not* do that, we normally work on smallish *different* packages or just a few people on the same package - so we normally don't get to feel the real *hurt* that a large commercial project often does. At least that is my perception.
Yes, MC and git are great. Darcs is in some respects even greater in this particular area (merging, cherry picking etc). But these tools do not capture what I like to call "developer intent" very good.
git and Darcs etc just manage files, they don't even know what language we are using. Darcs has something in the "right direction" and that is the token replace change, which is a small step towards "smarter change types".
MC knows it is Smalltalk source it is dealing with, but doesn't really use that knowledge as much as it could.
Deltas that I started working with (and came quite far with the help of Matthew Fulmer and a few others) goes a few steps further. A Delta distinguishes developer intent in greater detail than MC and could potentially be "smarter" because of that.
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.
- 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.
regards, Göran
On 1/29/12 9:43 PM, "Göran Krampe" goran@krampe.se wrote:
Deltas that I started working with (and came quite far with the help of Matthew Fulmer and a few others) goes a few steps further. A Delta distinguishes developer intent in greater detail than MC and could potentially be "smarter" because of that.
What is the state of Delta ?
Dead ? Stopped for lack of time ? You have a killer in this but sell to Microsoft / CIA / KGB and can't share ?
Edgar
Hi!
On 01/30/2012 06:17 AM, Edgar J. De Cleene wrote:
On 1/29/12 9:43 PM, "Göran Krampe"goran@krampe.se wrote:
Deltas that I started working with (and came quite far with the help of Matthew Fulmer and a few others) goes a few steps further. A Delta distinguishes developer intent in greater detail than MC and could potentially be "smarter" because of that.
What is the state of Delta ?
Last time I coded on it the Deltas themselves were almost complete. I then created Tirade as a good format for them, and then got distracted by other stuff.
Dead ? Stopped for lack of time ?
Yeah, lack of time basically. Since it was only me, Matthew and Igor working on it. Matthew has other stuff on his mind, and so does Igor.
So... if someone would like to reawaken the project I would be more than happy to dig in and help out, much more fun working on it if I am not alone.
You have a killer in this but sell to Microsoft / CIA / KGB and can't share ?
What?
regards, Göran
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
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
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."
On 31 January 2012 12:46, Ben Coman btc@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_!
frank
Hi guys,
This idea about realtime non-invasive notifications of others activity in the group is actually interesting and quite close what we are seeing in realtime web apps recently. I namelly see the Facebook-like business collaboration as a growing trend and one of more interesting innovations there is how to get notified without being disturbed, non-invasive therefore. I think we can copy some ideas from there to our tools too.
Janko
S, Göran Krampe piše:
- 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 :)
squeak-dev@lists.squeakfoundation.org
-
Ben Coman -
Edgar J. De Cleene -
Frank Shearar -
Göran Krampe -
Hans-Martin Mosner -
Janko Mivšek