Luis: it is a concern. I wasn’t trying to say its not a concern – of course its something to think about. I’m saying that the net effect is easier returning of changes, rather than a net effect of easier-forked and not-merging code.
I completely agree that it is a social phenomenon that we’re dealing with. I don’t agree that the tools are the fundamental problem – way back when folk used patch to send everything around, forking and merging was common. These days its become a hidden thing with month long forks in a home dir while a feature is coded, and then finally committed, but I think the basic process has stayed the same: someone works on some code and collaborates via patch and diff with peers until its ready, when someone that has ‘commit access’ puts it in the mainline.
There seems to be a strong persistent meme that distributed VCS’s – Bazaar/Cogito/Montone et al – make it easier for people to fork projects and not return changes. I.e. to have ‘my libxml2’.
I think its important to note that people do this already, easily, by simply doing svn co svn://host/trunk. That is immediately a fork as soon as a change is made.
All a distributed VCS does is make it easier to return changes to the project.
Well, back at work aftersome much needed leave. Just before returning I attended the local Twisted Sprint, which was a great deal of fun. Amongst the things achieved are documentation improvements, a TDD variation of the finger example (which needs tidying up and human text to be put in the documentation), discussion of barriers to entry with Twisted, and last but not least, some refactoring of trial to fix a couple of annoying bugs, and prepare for making it not clash with unittest anymore.