> 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 <[email protected]> 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!
