From e120674fe22151d0a1ae221fba0c26fa848aecee Mon Sep 17 00:00:00 2001
From: Greg Price <price@mit.edu>
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