SCM innovation in monotone

Posted Apr 25, 2005 12:14 UTC (Mon) by karath (subscriber, #19025) [Link]

It is interesting how the git project has taken off. Obviously, one major contributing factor is that Linus Torvalds started it. But he also started sparse and, while it is successful [1], it has not taken off in the same way [2]. So there must be much more to git than just the name of the founder.

The fact that, so soon after inception, git will have to handle the patch flow of the Linux kernel project (which in volume terms has to be the biggest of any free or open source project) has several implications. There is the technical performance aspect. But also the human scalability - Linux is too big and too open to tolerate a centralised approach to commit privileges (and the resulting flame wars and forks over loss of commit privileges). And of course, Linus has some very definite (but evolving) opinions about what makes a good SCM and the processes that he wants around such an SCM.

Another interesting area is the separation of the core file system-like plumbing from front ends. git-pasky (soon to be cogito - "git inside") looks to be the primary front end but there are others, including several separate web front ends. However, while there are certainly some areas of policy that can be chosen by the front ends, given the core design choices embedded in the plumbing/file system like design of the git core, it is not clear how much the separation of policy and plumbing there is.

Already, at least two other SCM projects are seriously looking at some level of integration with git.

For darcs, <http://marc.theaimsgroup.com/?l=git&m=111438196021900...> announces a patch for "A darcs that can pull from git". The same message suggests that there is a further independent investigation of how to integrate darcs and git.

And Tom Lord, not often known for accepting other people's ideas about SCM, never mind their code, announced (see <http://marc.theaimsgroup.com/?l=git&m=111399113920590...>) that "'git' technology will form the basis of a new archive/revlib/cache format and the basis of new network transports".

While progress appears to have been very rapid, there have been some negatives for the early adopters. There have been two file format changes that have led to problems for some (one was to regularise date formats and the other changed the order of SHA-1 hashing and compression to improve performance).

And for the larger kernel process, there is a hiatus while the new system is being developed and matured [3]. But there is a good chance that adopting any of the existing SCM systems would have had a similar delay while the major protagonists got used to it. My memory is that (leaving aside the flame wars), there was a much longer period of transition when BK was first adopted.

There is an interesting message at <http://marc.theaimsgroup.com/?l=linux-kernel&m=111426...> where Linus suggests that a tool such as quilt may be more effective for the messy early stages of development of a patch (patchset). git keeps all of the history and does not allow retrospective editing. Therefore, the only way to cleanup the history of a patch is to export a patch from the dirty/messy git tree and then import into a clean tree [4]. So, despite, all the progress, it looks like there is still some way to go before there there can be a single integrated tool supporting the Linux kernel workflow.

regards,
Charles

[1] Successful in that it has driven several campaigns of type-checking cleanup in the kernel. I do not know if it is used outside the kernel (i.e. I'm too lazy to research this).

[2] For example, if my memory is correct, Linus suggested on a couple of occasions that he would like to see someone take sparse all the way through to actually generating runnable kernel code to "prove" that it was correct.

[3] It is interesting that transitioning of the SCM came hard on the heels of the "sucker" super-stable kernel tree process change. I suspect that when all has settled down, "history" will note this time as one of huge change in the Linux kernel process.

[4] There was a similar message from Larry McVoy last year, see <http://marc.theaimsgroup.com/?l=linux-kernel&m=109874...>, where he agreed that the quilt type workflow was valid and he did not yet know how to integrate it into BK.