 - if someone specifies :project in a config repo block in a localized config (say a RAILS app), then use that for determining which project to use when loading the config repo

 - batch deployments (--batch=/etc/deploy/hourly.yml)
   - could have this simply pointing to a single yaml file with project name, target name, check value (default = true) (business value:  only need one command, or one cron, to manage all of these)
   - could be a directory of individual yaml files with that information in each of them (representing one project, one target) (business value:  puppet/chef could more easily manage directories of files)
   - trying to avoid re-using the deploy.yml because we may want to not auto-deploy all things that we have configurations for, or we may want to auto-deploy them at different frequencies
   - do we want the config path to be in the meta file, or do we want that to come as part of the arguments to the deployment?

     wd deploy --batch=/etc/deploy/hourly.yml --path=/etc/deploy/projects/
     wd deploy --batch=/etc/deploy/hourly/ --path=/etc/deploy/projects/
     wd deploy --batch=/etc/deploy/hourly.yml --path=/etc/deploy/deploy.yml
     wd deploy --batch=/etc/deploy/hourly --path=/etc/deploy/projects/deploy.yml

 - allow whiskey_disk to pull configuration file from an url (which would be based on project, environment)

 - do git-deploy style change detection:  
   - get the current branch ref, then do the fetch/reset, get the current branch ref; find the differences, make them available to the rake task(s)
     we can use the ml/cl part of staleness checking to get the "before" versions of the main and config repos (i.e., leave that part in always, just not the conditional stuff), and have the main run a script which dumps the relative paths of changed files as a .whiskey_disk-paths-changed in the main checkout
     
   - some sort of simple API to access the detected changes:
     require 'whiskey_disk/rake'
   
     namespace :deploy do
       task :post_deploy do 
         if changed_in?('db/migrate') or changed?('config/database.yml')
           Rake::Task['db:migrate'].invoke
         end
         # etc. ...
       end
     end

 - [Q] what about maintenance pages(?) (i.e., do we need a pre-deploy hook?; also are these per-target config stuffs?; fun managing changes to a maintenance page ;-)
 - [Q] do we want a mechanism to manage the config repo?  (add a repo, add a project, add an environment, put a file into the config repo for an environment?)
 - [Q] what about per-target rake tasks, do we just store these in the config repo?  does this work?
 - [Q] do we need actual support for "rollbacks"?
 - [Q] do we want to support multi-system deployments (i.e., deploy and rollback on 4 simultaneous app servers, other bullshit running on the db server, etc.)?  If we get into this, we have the original :role problem that cap faced -- i.e., we only want to run the database operations on certain hosts.
