While there are quite a few people using central VCS's like svn and cvs for hosting packaging repo's and building from them using automated tools - is anyone away of a decentralised setup using either Hg or Git ?
On Fri, Nov 07, 2008 at 02:11:25AM +0000, Karanbir Singh wrote:
While there are quite a few people using central VCS's like svn and cvs for hosting packaging repo's and building from them using automated tools - is anyone away of a decentralised setup using either Hg or Git ?
We have an embedded-ish mini-distro based on Fedora, for which the sources are kept in git, with the local branches based on the F-8 branches in the repositories of the Fedora CVS->git conversion available here:
(Unfortunately, rsync access to the Fedora CVS server was disabled after the Great Security Incident, and when I asked about having it re-enabled they told me they couldn't do it because of an infrastructure freeze -- so the git conversion isn't updating for now.)
Lennert Buytenhek wrote:
We have an embedded-ish mini-distro based on Fedora, for which the sources are kept in git, with the local branches based on the F-8 branches in the repositories of the Fedora CVS->git conversion available here:
do you really not use packages with $name[0] > a ?
On Fri, Nov 07, 2008 at 01:05:58PM +0000, Karanbir Singh wrote:
We have an embedded-ish mini-distro based on Fedora, for which the sources are kept in git, with the local branches based on the F-8 branches in the repositories of the Fedora CVS->git conversion available here:
do you really not use packages with $name[0] > a ?
They are there, they're just not on the front page.
E.g.
http://fedora.gitbits.net/?p=gcc;a=summary http://fedora.gitbits.net/?p=glibc;a=summary http://fedora.gitbits.net/?p=rpm;a=summary
Lennert Buytenhek wrote:
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 ?
On Fri, Nov 07, 2008 at 01:29:33PM +0000, Karanbir Singh wrote:
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.)
Lennert Buytenhek wrote:
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?
Most of this goes into the spec file itself. There are some things that are package dependant and not carried in the spec file - eg, the perpackage builder hints. But yes, I see your point. However, in the CentOS context, tracking this info with the package is easiest ( eg. which packages contribute to mixed arch, or even more complex when only some subpackages from the present package are contributed when the main package is not ).
(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.)
Its not that corner case for us in the CentOS builder setups, we handle most things for the entire distro as a single collection and run branches for the entire trunk/ with each major released! Even signaling for the buildsystem is being done via a tag across the entire distro tree, and we do that a few times every release.
This is the sort of thing I meant with my 'thinking in svn terms'...
but thanks for your feedback, its helped confirm and reenforce the lines that I was thinking about as well.
Hi Lennert,
Lennert Buytenhek wrote:
(Unfortunately, rsync access to the Fedora CVS server was disabled
I thought you might want to know that rsync access is available to the fedora-cvs store again ( just looked a few days back and noticed your store was not update ) . Try this :
rsync cvs.fedoraproject.org::pkgs/rpms/
- KB
-
Karanbir Singh -
Lennert Buytenhek