Re: [Tinycc-devel] Newer tinycc repository?

[KHMan]

Sanghyeon Seo wrote:
> 2007/10/30, KHMan <address@hidden>:
>> ... 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