Is there a way to specify a friendly name for a deployment when using the Force.com migration tool? 

When I deploy with changesets, the name of the changeset shows up in the deployment status page. 

When I deploy with ant using the <sf:deploy> task, the name ends up being a raw salesforce GUID. (Name: 0Af6100000v0o3E, as an example)

It seems obvious that there should be a name property to the sf:deploy task, but there isn't as far as I can tell?

I've got an object defined with an "external ID" field (in this case, email address).

We've got code that takes real-world values and upserts them into this object.  We don't bother querying for matches first - we just upsert the given values, knowing that the object they will either insert (if new) or update (thus resolving to the correct ID).  Either way my SObjects are guaranteed to have a valid ID post-upsert.

However, if I run enough processes in parallel, I'll get an upsert error:

EXCEPTION: Upsert failed.  First exception on row 0; first error:
DUPLICATE_VALUE, duplicate value found: i__FullAddr__c duplicates value on record with id: a0T700000003bX4

I'll investigate using the Database.upsert() method to retry the upsert on failure; hopefully that will fix the problem.

Am I smoking crack to think that upsert should be an atomic operation?  This is empirically not the case - we've clearly got interleaved upserts - but is this a bug or a "feature"?

I've got an object defined with an "external ID" field (in this case, email address).

We've got code that takes real-world values and upserts them into this object.  We don't bother querying for matches first - we just upsert the given values, knowing that the object they will either insert (if new) or update (thus resolving to the correct ID).  Either way my SObjects are guaranteed to have a valid ID post-upsert.

However, if I run enough processes in parallel, I'll get an upsert error:

EXCEPTION: Upsert failed.  First exception on row 0; first error:
DUPLICATE_VALUE, duplicate value found: i__FullAddr__c duplicates value on record with id: a0T700000003bX4

I'll investigate using the Database.upsert() method to retry the upsert on failure; hopefully that will fix the problem.

Am I smoking crack to think that upsert should be an atomic operation?  This is empirically not the case - we've clearly got interleaved upserts - but is this a bug or a "feature"?