Gentoo Logo
Gentoo Spaceship

Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-scm
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
To: gentoo-scm@g.o
From: Michał Górny <gentoo@...>
Subject: GIT->rsync
Date: Mon, 19 Apr 2010 17:31:28 +0200

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

signature.asc (PGP signature)
Re: GIT->rsync
-- Jeremy Olexa
Lists: gentoo-scm: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Thin Manifests for git
Next by thread:
Re: GIT->rsync
Previous by date:
Re: Thin Manifests for git
Next by date:
Re: GIT->rsync

Updated May 23, 2012

Summary: Archive of the gentoo-scm mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.