Update git-hooks notes with new vision for how git works.
authorEvan Broder <broder@mit.edu>
Mon, 12 Oct 2009 06:16:24 +0000 (02:16 -0400)
committerEvan Broder <broder@mit.edu>
Mon, 12 Oct 2009 06:16:24 +0000 (02:16 -0400)
svn path=/trunk/scripts/git-hooks/; revision=2498

notes

diff --git a/notes b/notes
index 716b3ad..e02346e 100644 (file)
--- a/notes
+++ b/notes
@@ -1,36 +1,30 @@
 
 
-on commit to submodule:
+on push to submodule:
+  error on non-fast-forward
+  error on pushing tag
   zephyr
-  nothing else?
 
-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
+superrepo heads are dev and prod
+on push to superrepo:
+  error - no pushes to superrepo
+
+on remctl xvm repo (dev|prod) package SHA-1:
+  use remctl ACLs to limit pushes to correct groups
+  verify that new version number is greater than previous
+  echo "(dev|prod) package SHA-1" > $build_queue/TIMESTAMP
 
-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
+while build queue is not empty:
+  find min(os.listdir($build_queue))
+  (as optimization: if same commit already in dev, just reprepro move)
+  try to build submodule
     if fail:
-      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
-  commit to foo
-  zephyr?
-  release lock
-if fail:
-  reset foo-incoming to old revision
-  send mail with log
+      keep build around
+      send mail with log
+      zephyr
+  upload to apt repo
+  tag submodule with version
+  commit superrepo with updated submodule
+  clean up build files
   zephyr
-  release lock
-
-Maybe there could be something sane without the lock?  It'd require
-more thought.
+  rm $build_queue file