anchor.diff:  Example:
   `/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=tech_categories`
   
  -== Deleting colocated collections
  +== Deleting Colocated Collections
   Deleting a collection which has been linked to another will fail unless the link itself is deleted first by using the
   <<collections-api.adoc#modifycollection, Modify Collection API>> to un-set the `withCollection` attribute.
   
   Example:
   `/admin/collections?action=MODIFYCOLLECTION&collection=techproducts&withCollection=`
   
  -== Limitations and caveats
  +== Limitations and Caveats
   
   The collection being used as the `withCollection` must have one shard only and that shard should be named `shard1`. Note
   that when using the default router, the shard name is always set to `shard1` but special care must be taken to name the
   shard as `shard1` when using the implicit router.
   
  -In case new replicas of the `withCollection` have to be added to maintain the co-location guarantees then the new replicas
  +In case new replicas of the `withCollection` have to be added to maintain the colocation guarantees then the new replicas
   will be of type `NRT` only. Automatically creating replicas of `TLOG` or `PULL` types is not supported.
   
   In case, replicas have to be moved from one node to another, perhaps in response to a node lost trigger, then the target
  
positive.code: // specific language governing permissions and limitations
  // under the License.
  
  Solr provides a way to co-locate a collection with another so that cross-collection joins are always possible.
  
  The co-location guarantee applies to all future Collection operations made either via Collections API or by Autoscaling
  actions.
  
  A collection may only be colocated with exactly one `withCollection`. However, arbitrarily many collections may be
  _linked_ to the same `withCollection`.
  
  == Create Collection using `withCollection`
  The Create Collection API supports a parameter named `withCollection` which can be used to specify a collection
  with which the replicas of the newly created collection should be co-located. See <<collections-api.adoc#create, Create Collection API>>
  
  `/admin/collections?action=CREATE&name=techproducts&numShards=1&replicationFactor=2&withCollection=tech_categories`
  
  In the above example, all replicas of the `techproducts` collection will be co-located on a node with at least one
  replica of the `tech_categories` collection.
  
  == Colocating existing collections
  When collections already exist beforehand, the <<collections-api.adoc#modifycollection, Modify Collection API>> can be
  used to set the `withCollection` parameter so that the two collections can be linked. This will *not* trigger
  changes to the cluster automatically because moving a large number of replicas immediately might de-stabilize the system.
  
negative.code: Example:
  `{'cores' : '<8', 'node' : '#ANY'}`
  
  The colocation guarantee is one-way only i.e., a collection 'X' colocated with 'Y' will always have one or more
  replicas of 'Y' on any node that has a replica of 'X' but the reverse is not true. There may be nodes which have one or
  more replicas of 'Y' but no replicas of 'X'. Such replicas of 'Y' will not be considered a violation of colocation
  rules and will not be cleaned up automatically.
  