[arch-dev-public] Git for the repos

Thomas Bächler thomas at archlinux.org
Wed Aug 24 17:37:56 EDT 2011

Am 24.08.2011 22:53, schrieb Florian Pritz:
> So it came up in IRC again and I'll try to sum up the discussion:
> SVN checkouts tend to break, some people only use it for our repos and
> not anywhere else, it's slow.
> We agreed on one git repo per package because you can't do partial
> checkouts in git and you hardly need the history of all packages anyway.

Let's get some details on the layout we discussed.

1) We have two 'package repository' folders, one for the developers, one
for the TUs.

In there, we have one repository per pkgbase, which contains PKGBUILD
and other files. You can use all the magic and awesomeness of git in
there, have several branches and whatnot. These repositories get a new
tag $pkgname-$pkgrel for each release.

These git repositories will not be affiliated with the package
repository/db, but only have information about specific versions of
packages. devtools will be responsible for creating and cloning them
when needed.

2) We have 'repository repositories' (nice name, hah), one for the devs,
one for the TUs (or maybe one for both). In there, we have a folder for
each package db/repository. These folders will contain a file for each
pkgbase that is currently in the repository. The contents of the file
should be a reference to the related package repository and the current
version (tag).

These git repositories would only be automatically be maintained by

The advantages of this scheme are:
1) We would use git, instead of shitty subversion.
2) The contents of all repositories will be useful.
3) The history of all repositories will be useful.
4) Everything will be gitweb-friendly.
5) Cats! Cute little cats!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-dev-public/attachments/20110824/06331e42/attachment.asc>

More information about the arch-dev-public mailing list