[arch-dev-public] Git

[Jan Alexander Steffens]

On Fri, Oct 4, 2013 at 6:15 PM, Alexander Rødseth <rodseth at gmail.com> wrote:
> Now, if I may, here's how your decisions on how you set up a git repo
> in place of svn affect us.  Right now, with the svntogit providing a
> merged repo of all the packages in two places (core/extra in one,
> community in another) allows me to simply poll the two git repos for
> changes and operate on that changeset.  This means that when packages
> get added, removed, or modified, I'm able to see everything that takes
> place.  If each package was to be split into its own git repo, I would
> need to devise some (potentially ugly) solution to scrape all of the
> current repos from somewhere, match them against what I know to exist,
> add packages (repos) that just got created and delete packages (repos)
> that just got removed, then further correlate which pacman repo each
> belongs to, if repos have changed, etc.  It would also require that I
> either find some way to determine which package git repos changed and
> only poll them, or potentially have to poll the ~4500 git repos that
> would exist individually.  In short, I don't know how I would
> accomplish this off the top of my head, and it could be a massive pain
> to implement.

To clarify, the individual git repos are just for tracking individual
package development. There still would be a central git repo
maintained by our dbscripts which reflects the status of all our
pacman repos. Either by using
submodules pointing at tagged commits in the individual git repos, or,
if submodules don't work out well, by copying the state of those tags,
maybe using git-subtree.

> My two cents toward the repo structuring would be to follow the same
> structure that is in place now with svntogit: have a packages.git that
> contains core and extra, which Arch developers have access to change,
> and a community.git that contains community, which devs and TUs have
> access to change.  Unless there is some overbearing need to
> individually delegate write access per package, individual git repos
> per package seems like it would be more of an administrative headache
> than it is worth (aside from destroying my current development model
> for Arch Linux ARM).  Should you decide to use a service like github,
> a combined package repo also means that community-generated pull
> requests are also combined, allowing more people to be notified of
> changes, submit their input, or merge changes when someone is on
> vacation.  A combined repo also means that you can delegate a
> 'testing' branch to contain all the testing versions of all the
> packages, allowing one to push/pull to all of the testing packages in
> one move, or merge a large set of changes back to stable, without
> having to go through and do the same operation on multiple git repos
> (I'm specifically thinking of things like the Gnome and KDE package
> sets).  One could potentially create a 'gnome-testing' branch, do all
> the changes and builds based on that branch, then when it's ready
> merge that branch back into stable and you're done.

When moving changes from testing to stable, the individual git repos
are not touched at all. They only track package versions, not which
pacman repos they are in (if any). Moving happens inside dbscripts,
which only needs to update the pacman repos and the central git repo
mentioned above.