List Archive: gentoo-scm
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
Another important topic related to the git migration is how rsync tree
is supposed to be created. Here is how I see it.
I. GIT repository side.
The only related mechanism at the GIT repository would be a post-commit
hook, sending a signal to the rsync server. The signal would only
notify the rsync side that the repository needs to be pulled, without
II. rsync server side.
The main part of the server layout is a hybrid git-rsync tree. It
starts as a GIT repository checkout, which is being filled with missing
data (i.e. ebuild checksums) by rsync scripting.
After receiving the signal, the rsync scripting pulls from
the repository and updates the working copy. Afterwards, it determines
which files have changed (using diffstat?) and calls repoman (or other
script) to regenerate the full Manifests for the related directories.
That's the simplest scenario. In fact, as our working tree would
contain Manifests changed for rsync users, most of the merges would
result in conflicts -- which should be resolved through always using
the remote version (as our own is going to be recreated anyway).
The problem is that git doesn't seem to like having conflicts with
local uncommited changes. Is there a way to force it to replace them
with the remote versions?
There would be probably some more problems related to file removal too.
Another useful thing would be atomization of the rsync updates to avoid
the possibility of downloading Thin Manifests by end user. The simplest
solution for that would be to keep two distinct trees, with working
tree being rsynced onto public tree after the updates are done.
But that requires keeping two copies of the tree, and doesn't provide
full atomization anyway (it's still possible that end-user downloads
partially copied directory, i.e. with new ebuilds and Manifest not yet
Thus, it'd be best to have the atomization (i.e. commit-update)
behaviour on filesystem level. If that's not possible, we could still
use poor man's solution similar to VGA page switching - two switching
rsync trees, one being used by end-users and the other being updated.