Distributed distributions

Does anyone know of any Linux/BSD/similar distributions that are employing a distributed/decentralized source code management system for their package trees?

To clarify, the difference that I’m interested in is as follows:

Distributed development tools such as git and mercurial allow everyone to clone the whole tree including all history. Everyone who does make a clone — let’s call it a branch — is able to commit new changes to their own branch, and can publish their branches. As everyone effectively has commit access, development hierarchy is built purely based on politics and personal standing (e.g. in the case of the Linux kernel, Linus is recognised as the boss, therefore his tree is ‘the one that counts’). Within reason, these systems all make it very simple (i.e. 1 easy command) to merge all the changes in someone elses branch into your own, even if the 2 branches are stored on different computers.

Centralized tools such as CVS and Subversion are different. There is a concept of ‘commit access’ to a centralized repository, and while anonymous read-only access may be granted for users who do not have commit access, such users can not make their own commits and do not have such an easy way of sharing their changes with the people who do have commit access to the centralized repository.

So, does anyone know of distributions that are using distributed systems for managing package trees? Gentoo uses the centralized approach — packages are maintained in CVS and we only give commit access to people who we certify and trust as Gentoo developers.

6 Responses to “Distributed distributions”

  1. Jonathan Dehan Says:

    I don’t know any distros that do it, but how hard would it be for a decent scripter to hack together something that would set up the portage tree like this and give the correct permissions to the correct people? – Find out who is responsible for what ebuild, create the correct logins and random passwords, and see what happens? It would be real easy to add sync support in paludis ( check /usr/libexec/paludis/syncers/ for examples ). You could even make a hook on –sync to upload any individual’s local overlay to the correct team responsible. I don’t know how distributed scms work but maybe new ebuild could be skipped on a user’s sync until they mark it official. This would keep the heirachy but also make it easy (and ecourage) people to maintain a few ebuilds and give back to the community/tree. If someone consistantly pumps out quality ebuilds, they can get permission to sync to the main tree…

  2. Corey Burger Says:

    Debian and Ubuntu both maintain various packages in a decentralized way, both with git and bzr. For Ubuntu the kernel is in git and on kernel.org and the bzr maintained stuff can be found at https://wiki.ubuntu.com/BzrMaintainedPackages

  3. Donnie Berkholz Says:

    Look into rPath. Their Conary system includes around the ability to branch and such.

  4. Christian Faulhammer Says:

    SourceMage uses Git.

  5. Aldrik Says:

    DSCM in general work on a workflow like :
    you clone locally
    you hack
    you make your local repository available or send the difference with main repository via mail

  6. genstef Says:

    For overlays.gentoo.org the usage you describe is already possible, see:

    http://www.kernel.org/pub/software/scm/git/docs/git-svn.html

    Unfortunately the official portage tree still uses cvs (and I see no real efforts of getting that fixed) :(

Leave a Reply

You must be logged in to post a comment.