Taras has recently upload a patch to bmo to remove outparam in QI. After I pulled his repos from hg.mozilla.org, I was not even able to run './configure'.
I was using a latest Mercurial 0.9.4, when I reverted to 0.9.1 everything worked fine. Upon investigation, I found that Taras used hg merging in those repos. Contrary to hg advertising, hg revision turns out *NOT* to be immutable. Different versions of hg treat the same of ChangeSets differently. This is an inherent flow rooting in delta model. With n ChangeSets and m algorithms to apply them, there is m^n variants (^ means power). It is perfectly fine as long as there is only *one* algorithm. But when merges come in, things really become complicated. Of course, there is a easy solution: to store intermediate states. And this is exactly how *git* works. Except from this stability, git may bring additional benefits to Mozilla. I would quote Linus Torvalds here from http://www.gelato.unsw.edu.au/archives/git/0505/2784.html > Note that we discussed this early on, and the issues with full-file > handling haven't changed. It does actually have real functional > advantages: > > - you can share the objects freely between different trees, never > worrying about one tree corrupting another trees object by mistake. > - you can drop old objects. > > delta models very fundamentally don't support this. The first point in the list is the top priority that Brendan Eich mentioned for the mozilla2 SCM system in March 2007: > [sic] we anticipate many experimental branches (for Tamarin work, > Oink/Elsa-based refactoring, etc.) and related integration branches > feeding back into the main Mozilla 2 branch. In fact, that is exactly the process, they develop linux kernel. Mozilla will only need an equivalent of '-mm' kernel branch to complete the picture. As a disclaimer I add that I am not counter-mercurial. I have svn, hg and git repositories set up for my project to facilitate cooperation. But I do personally prefer git to manage my working tree since its stability gives me a feeling of protection. -- Sergey Yanovich - abstract ERP leader _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
