The idea of a distributed version control system appeals to my anarchist ideals. By making it cheap to fork projects, people will be better able to persue new lines of development. By allowing patches to easily be shared, the best ideas can be more easily be brought together. It promise to allow be faster development with less politics. There are no hierarchies. All branches are are on equal footing.
After a few years of working with tla, I have some serious issues with it. It is a highly bureaucratic system. I had hoped the bureaucracy would be an advantage; that it would force a certain amount of consistency. However, if there is some advantage, I haven’t seen it yet. I can overlook many of the short comings of tla but there is one huge problem: star-merge.
In the star-merge style of development each developer works in their own repository. Cooperation is achieved by merging changes to and from a common repository. This style of development means that special “development” directories are no longer needed. The problem is that the
star-merge command only works properly so long as all the developers maintain a tree-topology with respect to each other. A tree-topology means that the graph of merges between repositories has no cycles.
We only had two developers, so you would think we’d have not trouble maintaining a tree-topology, however we still managed to screw it up. We were maintaining branches of CoRN not only for development, but branches that would work with both released and development branches of Coq. Keeping a tree-topology while merging patches between different branches of CoRN proved to be too difficult, and manual intervention was often needed.
The problem is that a tree-topology is a global property, but developers can only see a local part of this graph. This makes maintaining a tree-topology impossible without centralized control, which is exactly what we want to avoid.
The lesson is clear. If your DVCS requires a tree-topology, it isn’t really a distributed system.