Date: Thu, 25 Aug 2011 22:09:07 +0000 (UTC) From: Vadim Goncharov <vadim_nuclight@mail.ru> To: freebsd-arch@freebsd.org Subject: VCS (Was: FreeBSD problems and preliminary ways to solve) Message-ID: <slrnj5di02.4nl.vadim_nuclight@kernblitz.nuclight.avtf.net> References: <35765857-1314243257-cardhu_decombobulator_blackberry.rim.net-329610575-@b2.c15.bise7.blackberry> <CAJ-Vmo=v0UkQarauKrvWKdjMTC81BwXmyhU__rnaQeL3z45L-g@mail.gmail.com> <slrnj5ddgp.4ck.vadim_nuclight@kernblitz.nuclight.avtf.net> <CAMBSHm8uX45k0M4on=5Cpw_CKoddA=4oJSNXpH7dGPt=Vy2HOw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi mdf@FreeBSD.org! On Thu, 25 Aug 2011 13:59:30 -0700; mdf@FreeBSD.org wrote about 'Re: FreeBSD problems and preliminary ways to solve': >> Here an interesting question arise, in the philosophy/VCS field. We see >> that Linux/git adopted model where "dictator" has, say, 17 lieutenant >> for key subsystems, and pulls changes from them, each of them have, say, >> 17 own subordinates from whose he pulls, and so on. Instead of that 17^2 >> people FreeBSD has the same 289 men directly commiting to repository. >> It is repository here which acts as a "dictator" from technical side, >> and that is definetely better (e.g. no "kill -SIGBUS Linus" factors). >> The difference is, those 289 key people in Linux *can* pull changes from >> lower tiers, but FreeBSD people - can't (of course not at all, but it is >> significantly harder to contribute here). It is a plain model. > I like that the Project is small enough that (1) I can be trusted to > commit to any of it, and (2) after a few more years of work on it, I > may very well know more than half of the code. It's not always > possible to have lots of functionality in a small code base, Umm, may be I was not clear. The question of trust is orthogonal to what I wanted to say. If the VCS machine is a "dictator", then any committer is trusted to commit to any part of repo, this is left as it is now. What I'm talking about is contributing. I can view a part of committer's workflow when a contributor wants to do something big. So, he has to do things in his own repo first, then make a big patch to send to his friend at freebsd.org, which will apply it and commit. Many boilerplate work. But there will be much more work if contributor periodically updates his work. It is will be a pain to merge changes. And with DVCS all history in contributor's repo could been merged to main FreeBSD repo as well. Think about Perforce and users/ & projects/ in our SVN - that's also too much overhead for most contributors. Suppose we have such VCS based around central repo. Because a central repo concept exists, I, as a contributor, do clone a *set of files*, neither just subtree as in SVN nor entire repository as in Git. The VCS maintains those set - sys/netinet/ipfw/*, sbin/ipfw/*, etc/rc.d/ipfw and a few files from sys/netinet/ (not all). Note those are individual files, based on a inode-like object in repo. My VCS copy set up to templates as in main tree (just like subversion-freebsd now). I do several commits to those files, the VCS automatically tracks changes from central repo to me. Then, when I'm done, those entire commit history from my branch could be imported by interested committer, not just resulting patch. Effectively an outside vendor branch, closely tied to it's native original freebsd.org, though. > but less code is better, and I wonder if FreeBSD's code size stays > smaller because we can all work on all of it. Nope. More solved tasks - that is what better. And less code/smaller & cleaner code/less people/etc. - these are just a manner, a way to achieve that goal, not the goal itself. Adjective is not a noun. -- WBR, Vadim Goncharov. ICQ#166852181 mailto:vadim_nuclight@mail.ru [Anti-Greenpeace][Sober FreeBSD zealot][http://nuclight.livejournal.com]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?slrnj5di02.4nl.vadim_nuclight>