Jump to content
- one git repo per package
- signed git tags for each (epoch:)pkgver-pkgrel (unique)
- branches unimportant, free for developer to use
- db-update checks to-be-published packages match tags in repos
- git show "$tag:$path"; also works in bare clones (no working copy)
- merge packages and community (rethink security setup)
- still use dev & tu groups
- maintain git repo of db contents for history
- subdirs for each repo-arch (core-x86_64, etc.)
- generate repo submodule
- maintain git repo of submodules matching db contents for history
- Easily find released versions of packages (just git checkout the tag)
- History of packages in repositories (can find out what was when where)
- Use git! (no stupid git-svn)
- Less rigid repository structure. Easily make multiple branches track development and release from.
- Tags are signed with our GPG keys
- historical ABS
2015-04-03 (Namespace experiment)
- keep all packages in a single repository, separated by namespaces
- only one repository to configure
- improves storage efficiency
- avoids local duplication of trees
- branches combining all the individual packages can be maintained via git read-tree
- this is even faster than git-subtree
- worsens locality and increases repo contention
- with packed objects and packed refs git is pretty good at dealing with lots of objects and refs, though, unlike lots of submodules
- smart http clients can interact with the namespaced refs as if they were separate repositories, see git-http-backend(1) and gitnamespaces(7)
- makes creating and deleting "repos" simpler: just push
- a post-receive hook should take care of creating or deleting the namespace HEADs using git-symbolic-refs
- if a master branch is created (old sha1 is 40 zeroes), point HEAD to it
- if a master branch is deleted (new sha1 is 40 zeroes), delete the HEAD
- does this work with the ssh protocol or the git daemon?
- can clone the whole repo, though the contained namespaces won't be pulled by default. they can be, though!
- how do namespaces interact with gitweb/cgit? do we even want to run that on the repo server?
- the web server might need to maintain individual repos anyway
- a post-receive hook could push updates to the web server
- the web server could poll the main repo and separate the namespaces into clones locall
- access control? I assume we want to disallow TUs from pushing to dev repos
- record user's group (dev or tu) when creating a namespace?
- although namespaces can be hierarchical, I'd rather have a flat namespace of packages than the packages/community distinction we have now