+++ This bug was initially created as a clone of Bug #795449 +++

Description of problem:
A manifest (M1) loaded into Org 1 (O1) can not be "moved" to oOrg 2 (O2) _after_ M1  in O1 has been overwritten with M2.

Steps to Reproduce:
1. Load a manifest (M1) into Org 1 (O1)
2. Load a _NEW_ manifest (M2) into O1
3. Load M1 into O2
  
Actual results:
Candlepin believes this M1 is already in use; however, it should technically be removed from the db having been overwritten by M2.

Subscription manifest upload for provider 'Red Hat' failed.
Reason: Runtime Error Batch entry 0 update cp_owner set created='2012-02-20 09:50:38.649000 -05:00:00', updated='2012-02-20 09:51:30.960000 -05:00:00', contentPrefix='', displayName='blah', account='blah', parent_owner=NULL, upstream_uuid='0fb93d0e-d868-47c6-9701-f571e9e6a432' where id='8a8b67c7359b39a201359b3e30b900a8' was aborted. Call getNextException to see the cause. at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError:2,598
If you are uploading an older manifest, you can use the Force checkbox to overwrite existing data.

Expected results:
M1 should be available to load in to another org has it has essentially been replaced by M2 in its original org (O1).

Additional Info:
The work-a-round here is to not support the moving of manifests and instead document that sysadmins must generate a new manifest for O2, this manifest could  / should be generated from a new distributor and could have matching QTYs as those in the original Manifest (M1)