Added script for analysing Apple's ubiquity logs.

[ADDED]     LOGS: Details what some of the known entries in Apple's ubiquity log output mean.
[ADDED]     A bash script that analyses your ubiquity log output and parses out some useful information for debugging.

LOGS

@@ -0,0 +1,39 @@
+Reading ubiquity log output.
+
+
+CoreData: Ubiquity:  <_PFUbiquityRecordsExporter: ...> ... exporting ...
+    This indicates that you have saved changes to a MOC to the store and iCloud is preparing to create a transaction log for them.
+    It details the managed objects whose changes will exported into the log.
+
+    Should be followed by:
+        CoreData: Ubiquity:  Initializing stack
+        CoreData: Ubiquity:  <_PFUbiquityRecordsExporter: ... Successfully wrote transaction log: ...
+        CoreData: Ubiquity:  Stack Changes:
+
+
+CoreData: Ubiquity:  Got final value for relationship: ... ... Object: ...
+    This indicates that a relationship is being modified as part of the changes written to the stack.
+
+
+CoreData: Ubiquity:  Baseline exists in the cloud, will evaluate other criteria to see if a new one can be rolled.
+    Core Data is considdering rolling your transactions into a new baseline snapshot.
+
+    Usually followed by:
+        CoreData: Ubiquity:  Not enough log bytes to roll: ...
+
+
+CoreData: Ubiquity:  <_PFUbiquityRecordsImporter: ...>: ... Finished scheduling logs with context: ...
+    Core Data has detected a new transaction log and is preparing to import it.
+    It details the transaction logs that are going to be imported.
+
+    Should be followed by:
+        CoreData: Ubiquity:  Changes applied for transaction log content, managed object context changes: ...
+            Details the changes that were imported into the store.
+        CoreData: Ubiquity:  Posting import notification: : ...
+            Details the notification that is sent to the app for importing the changes into its MOCs.
+
+
+CoreData: Ubiquity:  <_PFUbiquityRecordsImporter ...>: ... Skipping log because it has already been imported into the local store: ...
+    Core Data has detected changes to a transaction log that has already been imported into the store and is ignoring them.
+
+    If you suspect this might be a cause of your issues, you could try deleting your sqlite file and letting Core Data rebuild it from the transaction logs.

README.markdown

@@ -120,6 +120,16 @@ If you read the previous section carefully, you should understand that problems
 
 Many of these methods take a `localOnly` parameter.  Set it to `YES` if you don’t want to affect the user’s iCloud data.  The operation will happen on the local device only.  For instance, if you run `[manager deleteCloudStoreLocalOnly:YES]`, the cloud store on the device will be deleted.  If `cloudEnabled` is `YES`, the manager will subsequently re-open the cloud store which will cause a re-download of all iCloud’s transaction logs for the store.  These transaction logs will then get replayed locally causing your local store to be repopulated from what’s in iCloud.
 
+## `parseLogs`
+
+The (`parseLogs`)[parseLogs] bash script allows you to analyse the output of Apple's verbose ubiquity log output and give you some feedback on it.  It is in a very young stage, but is aimed at aiding with debugging any iCloud related sync issues.
+
+To use the script, just run it (with PWD set to the location of the script or after copying its `bashlib` dependency into `PATH`), feeding it the ubiquity log over `STDIN`:
+
+    ./parseLogs < myapp.logs
+
+To make it more verbose, add `-v` options.  Verbose output will show unprocessed log lines as well.  It is the aim of this script to process all log lines output by Apple's ubiquity logging.  You can contribute either by amending the script or the (`LOGS`)[LOGS] summary file.
+
 # Under The Hood
 
 `UbiquityStoreManager` tries hard to hide all the details from you, maintaining the persistentStoreCoordinator for you.  If you're interested in what it does and how things work, read on.