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:
Thanks to everyone involved with pushing this. I can not wait to get rid of SVN. Doing anything but the most trivial operations is a huge PITA. A few comments below: On Wed, Aug 24, 2011 at 11:37 PM, Thomas Bächler <thomas@archlinux.org> wrote:
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.
Was this a typo? I guess the tag should be $pkgver-$pkgrel (as $pkgname is the name of the repo, so not needed, and without $pkgver the tag is not unique).
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 dbscripts.
This sounds reasonable. My only additional comment is that maybe using git submodules would be useful for these "repository repositories"? If every package repository is a submodule of the repository repository (need a better name for this), then git would keep for us exactly the information you outlined above (if I understood it correctly). The added advantage of using submodules would be that people could checkout the 'repository repositry' (again, needs a new name) without checking out any package repositories, and then use "git submodule update $pkgname" to get just the package repositories they want (in the same way we use "svn update $pkgname" today). Cheers, Tom PS There should be ponies!