anchor.diff:  path: .
   ~~~
   
  -This path correctly directs `cf` to the application when you run `cf` from the `nifty-gui` directory. All is well as long as `manifest.yml` is located there. If you move `manifest.yml` but fail to edit the path line to reflect the change, `cf` can no longer find the application, even if `cf` can still find the manifest.
  -
  +This path correctly directs `cf` to the application when you run `cf` from the `nifty-gui` directory. All is well as long as `manifest.yml` is located there. If you move `manifest.yml` but fail to edit the path line to reflect the change, `cf` can find neither the manifest nor the application.
  +
  +## <a id='precedence'></a>Precedence between Manifests, Command-line Options, and Leftover Values ##
  +
  +Application attributes can be set by a manifest or by use of `cf push` command-line options. If not set in either of these ways, attributes are set to reasonable values when you push an application for the first time. On subsequent pushes, you can use either command-line options, manifests, both, or neither. Values that are untouched by command-line options or manifests persist from push to push—we can call these leftover values.
  +
  +Whenever you push an application, `cf` applies rules of precedence when determining which attributes are set by command-line attributes, which by manifest, and which by leftover values:
  +
  +* Manifests override leftover values
  +* Command-line options override manifests
  +
  +Think of manifests as just another input to `cf push`, to be combined with command-line options and leftover values.
   
   ## <a id='optional-attributes'></a>Optional Attributes ##
   
  
positive.code:   RACK_ENV: ${rails-env}
  ~~~
  
  While the application is running, you can view, set, and unset environment variables using `cf`:
  
  ~~~
  cf env <app>
  cf set-env <variable_name> <variable_value>
  cf unset-env <variable_name> <variable_value>
  ~~~
  
  Environment variables interact with manifests by somewhat complicated rules:
  
  
negative.code: memory: 1G
  instances: 1
  services:
    clockwork-mysql
  applications:
  - name: springtock
    host: tock09876
    path: ./spring-music/build/libs/spring-music.war
  - name: springtick
    subdomain: tick09875
    path: ./spring-music/build/libs/spring-music.war
  ~~~
  
  In the next section we carry this principle further by distributing content across multiple manifests.
  
  ## <a id='multi-manifests'></a>Multiple Manifests with Inheritance ##
  
  A single manifest can describe multiple applications. Another powerful technique is to create multiple manifests with inheritance. Here, manifests have parent-child relationships such that children inherit descriptions from a parent. Children can use inherited descriptions as-is, extend them, or override them.
  
  Content in the child manifest overrides content in the parent manifest, if the two conflict.
  
  This technique helps in these and other scenarios:
  
  * An application has a set of different deployment modes, such as debug, local, and public. Each deployment mode is described in child manifests that extend the settings in a base parent manifest.
  