Fixed: attempt to establish a relationship between objects in different contexts
Using [updatedObject changedValues] rather than -changedValuesForCurrentEvent in order to get correct values

Only sending values for keys with changes in update request
Bumping to version 0.3.1
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
Update README.md
Update README.md
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
Merge pull request #105 from coryalder/patch-1

Fixes typo in objectIDforEntity:withResourceIdentifier:
Replacing == nil check to more conventional !
Merge branch 'fetch_request_overwritten' of https://github.com/aprato/AFIncrementalStore into aprato-fetch_request_overwritten
Minor cleanup on -executeFetchRequest:withContext:error:
Merge branch 'master' of https://github.com/stylemarks/AFIncrementalStore into stylemarks-master
Adding comment about why saveChangesRequestCopy is created
Merge branch 'apply_value_across_context' of https://github.com/pitiphong-p/AFIncrementalStore into pitiphong-p-apply_value_across_context
Refactoring and renaming applyValueFromManagedObject:toBackingObject: to updateBackingObject:withAttributeAndRelationshipValuesFromManagedObject:
[Issue #122] Removing unused AFIncrementalStoreDelegate forward declaration

Signed-off-by: Mattt Thompson <m@mattt.me>