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