Selecting to upgrade a service in the local charm upgrade inspector upgrades the services charm
Merge pull request #151 from mitechie/update-git-docs

- Update the fetch-pr alias per suggestion from Gary to add the +ref.
- Rename the juju-sync to sync-juju to start the trend of available sync-* commands
- Add a sync-trunk which will do a rebase from your develop branch.
- Update docs on how to keep your feature branch up to date based on the latest upstream trunk.
Ability to deploy units to specific machines.
Merge pull request #154 from mitechie/update-push-docs
added tests for the local charm upgrade functionality
Merge pull request #152 from frankban/add-to-machine-spec

Ability to deploy units to specific machines.

Support ToMachineSpec in goenv backend 
ServiceDeploy and AddServiceUnits calls.

Also update the pyenv for compatibility.

Drive by fix to code indentation/style.

QA:

Ensure the sandbox mode works well:
- make prod;
- deploy a service, add units, check
  everything is fine.

Live test the functionality on an ec2
environment:
- juju bootstrap -e ec2 --upload-tools
- juju deploy -e ec2 juju-gui --to 0
- juju expose -e ec2 juju-gui
- juju set -e ec2 juju-gui juju-gui-console-enabled=true juju-gui-source="https://github.com/frankban/juju-gui.git add-to-machine-spec"
- when the GUI is ready, log in, open the JS console;
- deploy a new service (e.g. mysql) as usual dragging the badge from
  the browser. This is done to ensure the usual way to deploy services
  from the GUI still works well: a new machine should be created to host
  mysql;
- add another unit to mysql using the inspector: at this point you should have
  mysql deploying to machines "1" and "2"
- using the console add a new machine, another new machine including an LXC
  container, and a new LXC on machine "1":
  app.env.addMachines([{}, {containerType: 'lxc'}, {containerType: 'lxc', parentId: '1'}]);
- use `juju status -e ec2` to ensure the new machines/containers have been 
  created: machine "3" and "4", containers "4/lxc/0" and "1/lxc/0"
- deploy wordpress to "1/lxc/0" by running the following:
  app.env.deploy('cs:precise/wordpress-21', 'wordpress', null, null, 1, null, '1/lxc/0');
- add another unit to wordpress, placing it on machine "3":
  app.env.add_unit('wordpress', 1, '3');
- define the following callback that will help visualizing
  the data returned by the API calls:
  var callback = function(data) {console.log(data)};
- ensure an error is returned when trying to deploy multiple units on
  the same machine:
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 3, null, '4/lxc/0', callback);
- deploy haproxy to machine "4" and container "4/lxc/0":
  app.env.deploy('cs:precise/haproxy-27', 'ha', null, null, 1, null, '4', callback);
  app.env.add_unit('ha', 1, '4/lxc/0');

Done, destroy your environment, thank you!
Merge pull request #153 from hatched/upgrade-from-local-charm

To QA
--------
**Use real env (ec2, lxc)**
- Deploy a local charm
- Drag the same local charm to the canvas, an inspector which gives you the option to upload or upgrade should come up
- Upload and deploy another version of the charm (so you now have two services with the same charm)
- Wait for both to come up.
- View the inspector for both services and take note of the charm url. One should be a higher version than the other.
- Drag the same local charm to the canvas and select a single service to upgrade.
- Wait 10s or so
- Click that services inspector and it should have a different charm url now.
Export constraints as a space-separated list.
Added integration tests for the local charm helper utils
Merge pull request #155 from bac/constraint-export

Make exported bundles write constraints as space-separated.

The fakebackend is changed to accept either the older comma-separated constraints or space-separated.
Merge pull request #156 from hatched/local-upgrade-tests

No QA needed, if it passes CI it's A-OK