15. Run parallel-find.pl
+* For mass importing into the repository, the steps are:
+
+[TO SET IT UP]
+# let app-1.2.3 be the scripts folder originally in deploydev
+# let this folder be srv/
+mkdir app
+cd app
+git init
+cd ..
+unfurl app-1.2.3 app
+# NOTE: contents of application are now in app directory
+cd app
+git add .
+git commit -s -m "App 1.2.3"
+git tag v1.2.3
+git branch pristine
+# NOTE: you're still on master branch
+mkdir .scripts
+echo "Deny from all" > .scripts/.htaccess
+touch .scripts/update
+chmod a+x .scripts/update
+# OPERATION: create the update script
+# WARNING: the following operation might require -p1
+patch -p0 < ../app-1.2.3/app-1.2.3.patch
+# NOTE: please sanity check the patch!
+git add .
+# NOTE: -a flag is to handle if the patch deleted something
+git commit -as -m "App 1.2.3-scripts"
+git tag v1.2.3-scripts
+
+[TO ADD AN UPDATE]
+# let this folder be srv/app.git
+git checkout pristine
+# NOTE: this preserves your .git folder, but removes everything
+wipe-working-dir .
+cd ..
+unfurl app-1.2.3 app
+cd app
+# NOTE: please sanity check app directory
+git add .
+# NOTE: -a is to take care of deletions
+git commit -as -m "App 1.2.3"
+git tag v1.2.3
+[IF THE PATCH HAS CHANGED]
+ # NOTE: Now, the tricky part (this is different from a real update)
+ git symbolic-ref HEAD refs/heads/master
+ # NOTE: Now, we think we're on the master branch, but we have
+ # pristine copy checked out
+ # NOTE: -p0 might need to be twiddled
+ patch -p0 < ../app-1.2.3/app-1.2.3.patch
+ git add .
+ # NOTE: DON'T FORGET THIS STEP!!! Otherwise fixing this is going
+ # to be painful later down the line
+ git checkout .scripts
+ # OPERATION: Check if the directory needs an updated update script
+ # NOTE: Fake the merge
+ git rev-parse pristine > .git/MERGE_HEAD
+[IF THE PATCH HASN'T CHANGED]
+ git checkout master
+ git merge --no-commit pristine
+git commit -as -m "App 1.2.3-scripts"
+git tag v1.2.3-scripts
+
+
* The repository for a given application will contain the following files:
- The actual application's files, as from the official tarball
* .scripts/database (generated) contains the database the
user installed the script to, so scripts-remove can clean it
+ XXX: Could cause problems if a user copies the autoinstall,
+ fiddles with the DB credentials, and then scripts-remove's
+ the autoinstall. Possible fix is to add the original
+ directory as a sanity check. Additionally, we could have
+ the application read out of this file.
+
* .scripts/version (generated) which contains the version
last autoinstalled (as distinct from the actual version
the script is) (This is the same as .scripts-version right