2013-08-25

Notes

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
- use this for ABS

Gains

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