| 1 |
Hello, |
| 2 |
|
| 3 |
Another important topic related to the git migration is how rsync tree |
| 4 |
is supposed to be created. Here is how I see it. |
| 5 |
|
| 6 |
I. GIT repository side. |
| 7 |
|
| 8 |
The only related mechanism at the GIT repository would be a post-commit |
| 9 |
hook, sending a signal to the rsync server. The signal would only |
| 10 |
notify the rsync side that the repository needs to be pulled, without |
| 11 |
further information. |
| 12 |
|
| 13 |
II. rsync server side. |
| 14 |
|
| 15 |
The main part of the server layout is a hybrid git-rsync tree. It |
| 16 |
starts as a GIT repository checkout, which is being filled with missing |
| 17 |
data (i.e. ebuild checksums) by rsync scripting. |
| 18 |
|
| 19 |
After receiving the signal, the rsync scripting pulls from |
| 20 |
the repository and updates the working copy. Afterwards, it determines |
| 21 |
which files have changed (using diffstat?) and calls repoman (or other |
| 22 |
script) to regenerate the full Manifests for the related directories. |
| 23 |
|
| 24 |
That's the simplest scenario. In fact, as our working tree would |
| 25 |
contain Manifests changed for rsync users, most of the merges would |
| 26 |
result in conflicts -- which should be resolved through always using |
| 27 |
the remote version (as our own is going to be recreated anyway). |
| 28 |
|
| 29 |
The problem is that git doesn't seem to like having conflicts with |
| 30 |
local uncommited changes. Is there a way to force it to replace them |
| 31 |
with the remote versions? |
| 32 |
|
| 33 |
There would be probably some more problems related to file removal too. |
| 34 |
|
| 35 |
Another useful thing would be atomization of the rsync updates to avoid |
| 36 |
the possibility of downloading Thin Manifests by end user. The simplest |
| 37 |
solution for that would be to keep two distinct trees, with working |
| 38 |
tree being rsynced onto public tree after the updates are done. |
| 39 |
|
| 40 |
But that requires keeping two copies of the tree, and doesn't provide |
| 41 |
full atomization anyway (it's still possible that end-user downloads |
| 42 |
partially copied directory, i.e. with new ebuilds and Manifest not yet |
| 43 |
updated). |
| 44 |
|
| 45 |
Thus, it'd be best to have the atomization (i.e. commit-update) |
| 46 |
behaviour on filesystem level. If that's not possible, we could still |
| 47 |
use poor man's solution similar to VGA page switching - two switching |
| 48 |
rsync trees, one being used by end-users and the other being updated. |
| 49 |
|
| 50 |
-- |
| 51 |
Best regards, |
| 52 |
Michał Górny |
| 53 |
|
| 54 |
<http://mgorny.alt.pl> |
| 55 |
<xmpp:mgorny@××××××.ru> |
Archives