From e120674fe22151d0a1ae221fba0c26fa848aecee Mon Sep 17 00:00:00 2001 From: Greg Price Date: Sat, 13 Jun 2009 18:59:08 -0400 Subject: [PATCH] update git-hooks notes to reflect asynchronous design svn path=/trunk/scripts/git-hooks/; revision=2358 --- notes | 23 +++++++++++++++++------ 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/notes b/notes index f79e7c3..716b3ad 100644 --- a/notes +++ b/notes @@ -4,22 +4,33 @@ on commit to submodule: zephyr nothing else? -superrepo heads are dev, prod +superrepo heads are dev, prod, and dev-incoming, prod-incoming on commit to superrepo: + reject commits to dev, prod + grab lock or fail + spawn build process + zephyr + +in build process for foo-incoming: for each changed submodule revision: (as optimization: if same commit already in dev, just reprepro move) try to build submodule if fail: - abort whole commit + abort whole build clean up any previous packages' built files, maybe keep this one's around remember package and version for each changed submodule revision: (if we're still going) tag submodule with version upload to dev/prod respectively clean up built files - actually commit + commit to foo + zephyr? + release lock +if fail: + reset foo-incoming to old revision + send mail with log zephyr + release lock -This makes a long pre-receive process. Is that cool? -Probably is the right thing. - +Maybe there could be something sane without the lock? It'd require +more thought. -- 1.7.9.5