update git-hooks notes to reflect asynchronous design
authorGreg Price <price@mit.edu>
Sat, 13 Jun 2009 22:59:08 +0000 (18:59 -0400)
committerGreg Price <price@mit.edu>
Sat, 13 Jun 2009 22:59:08 +0000 (18:59 -0400)
svn path=/trunk/scripts/git-hooks/; revision=2358

notes

diff --git a/notes b/notes
index f79e7c3..716b3ad 100644 (file)
--- a/notes
+++ b/notes
@@ -4,22 +4,33 @@ on commit to submodule:
   zephyr
   nothing else?
 
   zephyr
   nothing else?
 
-superrepo heads are dev, prod
+superrepo heads are dev, prod, and dev-incoming, prod-incoming
 on commit to superrepo:
 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:
   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
       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
   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.