Fixed: attempt to establish a relationship between objects in different contexts
Fixed a typo in AFIncrementalStore.m

Fixed what I'm 90% sure is a typo.
You've set `objectID` to nil, so `objectID.entity.name` will also be nil. I'm pretty sure this should be `entity.name`.
I noticed this while reading through the code trying to understand how it deals with object ids, so I can't attest to a problem caused by this or if this change will break anything. Hope it's helpful, tho!
Use AFResourceIdentifierFromReferenceObject for reference the identifier in the backing context

Thanks @conradev for the point.
https://github.com/AFNetworking/AFIncrementalStore/pull/103#issuecomment-10517348
Fix empty NSSaveChangesRequest notifications.

The original instance of NSSaveChangesRequest was passed to both
`AFIncrementalStoreContextWillSaveRemoteValues` and
`AFIncrementalStoreContextDidSaveRemoteValues`.

The probleme here was that CoreData removes the objects from the sets
referenced in the original request as they are saved. This means that
from a notification handler for
`AFIncrementalStoreContextDidSaveRemoteValues` you are provided with an
`NSSaveChangesRequest`instane whose sets are either empty or nil,
leaving you unable to get a reference on the managed objects.

This is fixed here by creating a new NSSaveChangesRequest with copies of
the original sets.
- Applied several fixes to the `applyValueFromManagedObject:toBackingManagedObject: method`:
1. Avoided crash that can occur if a related object is currently waiting on a network request before obtaining a permanentID. The fix checks to see if an objectID is not temporary before adding to backingRelationshipObjects.
2. Fixed apparent typo that was attempting to find the objectID for the backing object of the source entity in the relationship. This only works if it checks for the destination entity of the relationship. This bug wouldn't be noticed if the relationship was between objects of the same entity, but it was causing objects to never get mapped in my project.
Stops executeFetchRequest:withContext:error: from modifying the incoming fetch request
Removing stray subscripted mutable dictionary access
Replacing == nil check to more conventional !
Minor cleanup on -executeFetchRequest:withContext:error:
Adding comment about why saveChangesRequestCopy is created
Refactoring and renaming applyValueFromManagedObject:toBackingObject: to updateBackingObject:withAttributeAndRelationshipValuesFromManagedObject:
[Issue #122] Removing unused AFIncrementalStoreDelegate forward declaration

Signed-off-by: Mattt Thompson <m@mattt.me>
[Issue #108] Don't pluralize words ending in 'se' with 'es'

Signed-off-by: Mattt Thompson <m@mattt.me>
Revert "Fixing formatting string for ISO 8601 parsing"

This reverts commit fd4bd1585b2ed94dd0b203377173efb34b020256.
Stashing first design
Changing pagination architecture to use <AFPaginator> object rather than blocks
Removing confusing log 

The example is logging the SQLite file/location. Since the example uses an ```NSInMemoryStoreType``` (as fallback?), there is no SQLite involved.  
[Issue #130] Removing override of -enqueueHTTPRequestOperation: that cancels any requests with the same method to the same path

Signed-off-by: Mattt Thompson <m@mattt.me>
Fixes a deadlock situation when the connection fails under some success, failure queue configurations

Signed-off-by: Mattt Thompson <m@mattt.me>
Fixing analyzer warning of method with NSError ** parameter (insertOrUpdateObjectsFromRepresentations:...) not returning a BOOL, as per convention