documentation/feisty_meow_command_reference.txt

   1
   2 These are the handiest commands available in the Feisty Meow scripts.
   3
   4 setup and loading commands
   5 ==========================
   6
   7 + read "readme.txt" in the top of the feisty meow codebase, or
   8 + read it online at: https://feistymeow.org/feisty_meow/readme.txt
   9
  10 revision control commands
  11 =========================
  12
  13 all revision control commands bring up the editor in the EDITOR environment
  14 variable when creating commit messages.  you need to actually save and quit
  15 from that editor when you're done writing your commit message.
  16
  17   here's a guide to writing good commit messages:
  18   + https://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
  19
  20 ========
  21 the first suite of commands takes a list of directory names as parameters and
  22 then operates on those names.
  23 ========
  24
  25   rgetem:
  26   does a simple update (or pull) of the repository paths provided on the
  27   command line.  this will only get things from the main origin that the
  28   repository is hooked up with, so it is super quick compared to the next
  29   couple commands.
  30
  31   rpuffer:
  32   update the repositories provided on the command line by "puffing them out",
  33   which means that the upstream repositories that feed the local one will be
  34   synched up with it.  this is quite important to do when a git repository has
  35   multiple branches, since unmerged changes upstream can really snarl up your
  36   checkin.  this is basically a heavyweight version of rgetem.
  37
  38   rcheckin:
  39   checks in the list of repositories passed on the command line.  in git
  40   parlance, this adds all modified or untracked files, then commits all
  41   changes in the repository, and finally pushes up the changes to the remote
  42   online repository.  before doing the checkin, this will do a full "rpuffer"
  43   update on the repository to ensure that there are no unmerged upstream
  44   changes that could cause problems later.
  45
  46 ========
  47 the next suite of commands uses the REPOSITORY_LIST environment variable as
  48 the set of revision controlled folders to operate on.  the feisty meow scripts
  49 automatically add the feisty meow top-level (the apex) to this list to ensure
  50 that updates are received when available.
  51 ========
  52
  53   getem:
  54   update all repositories in the REPOSITORY_LIST from their upstream remote
  55   counterparts.  fast.
  56
  57   puffer:
  58   puffs out the REPOSITORY_LIST items to merge upstream changes.
  59
  60   checkin:
  61   checks in all changes in the REPOSITORY_LIST to their remote repositories.
  62
  63 ========
  64 some assorted other revision control commands:
  65 ========
  66
  67   feisty_branch:
  68   shows the current branch that is checked out.
  69
  70   this command will move your feisty meow codebase to the development branch:
  71   pushd $FEISTY_MEOW_APEX; git checkout dev; popd
  72
  73   and this command will get you back onto the mainline branch:
  74   pushd $FEISTY_MEOW_APEX; git checkout master; popd
  75
  76 =============================
  77 the site avenger script suite
  78 =============================
  79
  80 the site avenger tools (inherited from the avbash project) are commands for
  81 managing web sites.  these scripts offer a lot of power to the developer, and
  82 of course that comes with great responsibility...
  83
  84 the site avenger scripts are configured by "app" files stored in the "config"
  85 directory (in $FEISTY_MEOW_SCRIPTS/scripts/site_avenger/config).  the scripts
  86 seek out a config file named after the application, e.g. they look for
  87 "winterportlibrary.app" if the application name is "winterportlibrary".
  88 the basic config file "default.app" is used for any application that is unknown
  89 in the config directory.  any of the variable definitions provided in
  90 default.app can be overridden to change how the applications, and associated
  91 web site and domain, are configured.  see "mapsdemo.app" for an example of
  92 overriding the domain name for the mapsdemo application.
  93
  94   revamp_cakelampvm:
  95   establishes permissions and ownership to make the virtual machine and its
  96   services behave properly.  if something goes wonky, try running this script.
  97   this script is also the main vehicle for delivering configuration changes
  98   to the cakelampvm.  we are trying really hard to never release a version 2
  99   of the vm, since we can patch it as needed using the revamp script.  let's
 100   see how well that works out...
 101
 102   standup:
 103   brings up an application or web site from scratch (potentially) by creating
 104   an appropriate domain name, writing a basic apache site config file, pulling
 105   the application from a git repository, and "powering up" the application via
 106   composer.  this is most powerful and effective on php sites, but can also be
 107   used for other types of websites.  note that this, and all of the scripts
 108   here, are heavily biased for site avenger based development at saco designs.
 109   to make these scripts truly your own, write configuration files (see above)
 110   that define the proper folders and repository for your applications.
 111
 112   teardown:
 113
 114
 115   powerup
 116
 117   avcoreup
 118   siteup
 119   sitepush
 120
 121 satis-refresh
 122
 123
 124
 125 lower level scripts used by site avenger scripts:
 126
 127   add_domain / remove_domain: (from system script collection)
 128   (the domain tools, for example, are
 129     very sensitive to edits within the chunks of code they have written.  if you
 130   need to edit bind config files, be sure to do it way above or way below the
 131   auto-generated domains.)
 132
 133   add_apache_site / remove_apache_site:
 134
 135
 136