Sanghyeon Seo wrote: > 2007/10/30, KHMan <[EMAIL PROTECTED]>: >> ... If there is a FLOSS project where commit access >> is *totally* open like a wiki, please let me know, it would be an >> interesting factoid to know. > > Linux kernel, Xorg, Wine, etc., in that they are using Git, and anyone > is free to commit to his local repository. I understand that you are > not familiar (and seemingly even hostile) to the distributed version > control, but you don't need to force your view to others.
Dear everyone, I realize this discussion goes into a lot of OT territory, but since it involves the future of tcc development, I don't wish to stay silent, and so I will try to clarify the dissonance to the best of my meagre ability and not chicken out. :-) The following are some extended comments, my last ones for now. Hopefully it will make things clearer and not worse. To clarify the use of git in distributed revision control, IIRC Linus has said of git that it is sort of a low-level distributed version control system, or a very fast versioned file system. git does not try to impose specific development models, but allows for maximum flexibility. hg also does not seem to impose specific development models as well. It is up to the developers' discipline to make development work... or fail. To claim that git is doing 'dis and 'dat is not enough, because git is just infrastructure -- it facilitates and does not try to constrain. What matters in, say, Linux development is the development model, the social construct that is agreed upon. How does changes filter into the main tree? When Linus pulls from one of his lieutenants, what is he assuming? When a module maintainer pulls from Linus or accepts patches from contributors, what are his or her assumptions and duties? Can we then consider the Linux social model to be trivial or unimportant, and instead consider git by itself to somehow, hold the "magic" and the key to distributed development? git does not impose much of anything; it is the social hierarchy that counts. Each developer is of course completely free to personally mess with his own repository (obviously) but here we are dealing with the entire system as a whole, that is, how to get tcc development moving among a multitude of mostly casual contributors with the minimum of effort and fuss and confusion. There is no "total" distribution in Linux development. There are hierarchies and bottlenecks. It is not a "cloud" of equal peers -- although in theory all are equal from git's viewpoint. Disputes happen and complaints exist. Features wanting to go into the main tree are supposed to change in tandem with the main tree, no ifs or buts. Linus or anyone else will most likely not pull an obsolete or out-of-date changeset and then spend the time to update the code for the latest version of the kernel. People who "sign off" code are expected to 'had better have seen and reviewed them code'. There are duties, responsibilities, trust networks, hierarchies. Note: All of this says nothing about git itself; it has all to do with the social rules of Linux development. Likewise, if Linus suddenly decides to use hg, not that much would change -- because the "intelligence" of that system does not lie in git. Now, I am studying a linux-2.6.21.3 tree, and it's 226MB in size. tcc is 1.6MB in size. Changesets from differing trees are more likely to conflict with each other in the latter. One problem is, tcc.c is a real hot hotspot. Just diff the Savannah CVS and the hg tip. Say, if you have half a dozen people hacking at tcc.c separately, splitting off into six branches, I wouldn't want to be the one merging or pulling from all of those into one place. I don't have the skills for that -- I still see in the hg documents that merging might bring up a graphical merging tool for the icky cases, so no magic wand there. So, whichever way we want to whack at tcc.c, surely, some form of coordination is helpful. Thus, I personally would highly prefer a "common denominator" to be decided early on, a tree we all agree upon where people can sync regularly with. I can now pull using CVS, SVN, git or hg, so I am quite neutral; it's really the social construct that I am blathering off about. If my reasoning is wrong, please provide a detailed rebuttal. Thanks, and that's all for now, -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia _______________________________________________ Tinycc-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/tinycc-devel
