Gentoo Archives: gentoo-scm

From: "Michał Górny" <gentoo@××××××××××.pl>
To: gentoo-scm@l.g.o
Subject: [gentoo-scm] GIT->rsync
Date: Mon, 19 Apr 2010 15:30:55
Message-Id: 20100419173128.33ae2090@pomiot.lan

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
further information.

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.

Best regards,
Michał Górny



File name MIME type
signature.asc application/pgp-signature


Subject Author
Re: [gentoo-scm] GIT->rsync Jeremy Olexa <darkside@g.o>