On Fri, Nov 07, 2008 at 01:29:33PM +0000, Karanbir Singh wrote: > >>> http://fedora.gitbits.net/ > >> > >>do you really not use packages with $name[0] > a ? > > > >They are there, they're just not on the front page. > > ah cool. it did seem a bit strange. So you guys decided on doing the > one git repo per package route... That is the route I dont want to > take with the centos stuff. Mainly : > > 1- how would one checkout a complete tree ( eg, i want a 5.2-ppc branch > checkout, and include all packages in that branch ) > > 2- adding a new package would mean adding knowledge about that package > at every step of the way from the packagers upto the build masters, arch > masters, testing stages, release and sign stage, mirror and push stages. > I suppose one might work around that a bit by having yet another git > repo that only has / tracks package status but that seems ugly. > > one thing that the repo-per-package route fix's for git is the ACL > issue. with everything in one git-repo, its tricky getting people-> > access levels going. Its almost a case of resorting to people doing > commits via patch on email. Which then in turn creates a bottleneck in > that only some specific people can commit into the builder-visible-repo. > > or am i just thinking too much svn'ish and not enough git'ish ? In git, you can't as easily checkout or commit to a subdirectory of a given repository as in CVS or svn, which was the reason for opting to put each package in its own repository, so that package maintainers wouldn't have to check out the source tree for the entire distro to maintain their package. And as you say, access control is another thing -- you _can_ apply commit-time checks to make sure that noone commits to dirs they don't have access to, but using unix permissions for that is just slightly easier. You _could_ pretty easily make a 'super-repo' that has each of the packages in the distro as subdirectories of one big dir, you could in fact do that pretty easily due to the way git works. But if the goal is to be able to add packages easily to run them through the entire build and release stage automatically, there's a bunch of metadata I can think of, both on the distro level (whether to build this package for i386 or i686 (glibc), whether to build it for i386 or not when you're building for x86_64) and the build level ("the kernel package should only be built on the octal core box") that you might want to encode somewhere that you don't have space for if you represent each package by just a directory in some other directory. So to me it would seem that all the metadata needed to build the distro should be something that you want to version control individually? (Note that the (1) use case is rather rare, and if you're not truncating history when checking out, you'll end up with a couple of gigabytes worth of checkout.)