Edits temporarily lost on sync if computer has already pushed other changes

[Matt McCutchen]

I'm seeing the following problem regularly with MobileOrg:

Starting with the computer and phone in sync:
1. Make a change on the computer.  It is auto-pushed using the code from the FAQ.
2. Make an unrelated change on the phone.
3. Press "Synchronize" on the phone.  The phone adds the change of #2 to mobileorg.org, but then it imports the file pushed in #1, replacing all previous data from that file and temporarily losing the change of #2.
4. Once I realize what has happened, pull and push on the computer and synchronize on the phone.

For example, yesterday I took my phone to the kitchen to make my grocery list, synchronized, and went out to the store with only the phone, to find the grocery list gone.  Luckily I remembered what was on the list.

Should I be doing something differently?  I would hate to have to remember to always synchronize after making changes on the computer and before making further changes on the phone; to me, that negates a lot of the value of a synchronization system.

I understand that under the current design, the phone relies on the computer to combine changes to a single org file.  Perhaps the phone could at least check, before importing a new file version, whether it claims to incorporate all edits previously made by the phone to that filename.  If not, the phone would skip the import and warn the user, who can complete #4 immediately if desired or continue using the phone with the data it has and complete #4 later.

Given that the synchronization currently imports before pushing edits, the condition to import would be: there are no edits to the file waiting to be pushed in the same synchronization, and the LAST_MOBILE_CHANGE field has changed since the last time the phone pushed edits to the file.  This should solve the most common case of edits being silently (temporarily) lost.  Edits would still be lost if the computer pushes while they are sitting conflicted in the mobile inbox, but the user will typically see when that happens.  Any suggestions before I submit a patch?

Thanks,
Matt

[Matt McCutchen]

I realized that checking LAST_MOBILE_CHANGE of the file that was originally edited on the phone is an incomplete solution because the target node could have been moved to another file on the computer or even deleted by the time the edit is pushed.

For now, I'm using a simple patch (attached) that skips the entire pull with a notification only if edits are being pushed on the same synchronization.  This should work as long as I see the notification before synchronizing again.  Since I don't know yet whether MobileOrg will meet my needs for me to use it long-term and no one else has shown interest in the issue, I'm not spending time on a better solution.  I'm not sure if this patch would be appropriate to take upstream, but at least anyone who has the same problem and finds this thread can try it.

[James Harkins]

On October 21, 2015 11:33:32 AM Matt McCutchen via mobileorg-android
<mobileorg-android+APn2wQeSh-7OTX...@googlegroups.com>
wrote:

> For now, I'm using a simple patch (attached) that skips the entire pull
> with a notification only if edits are being pushed on the same
> synchronization. This should work as long as I see the notification before
> synchronizing again.

I'm at some pains to imagine how to handle it better than this (not that it
matters, as I'm only a user, not a developer of this tool).

If it's a new node, it would be reasonable to keep it in the phone until
the node comes back in a sync operation after pushing on the computer --
that is:

1. Make a new node on the phone.
2. The computer has auto-synced some changes.
3. In mobileorg on the phone, do a sync. This brings in new stuff from the
computer. Currently this also deletes new stuff from the phone. For the
sake of argument, let's pretend that it leaves new content in the phone.
4. Further updates in the computer, then org-mobile-push (C-c C-x RET p).
5. Sync again on the phone.

Step 5 should remove the new content saved locally in the phone and replace
it with the pushed material from the computer. But how do you match it up?
The user may have made any change to the headline text, or moved the
headline elsewhere in the file (or even into another file), and mobileorg
on the phone has no knowledge of, or control over, it. I guess you could
add a MOBILEORG_ID property with a GUID in the phone, but you can't
guarantee that the user won't remove it or tamper with it on the computer.

This isn't an answer, but I hope at least an acknowledgment that
mobileorg's current behavior is because it's a Difficult Problem.

hjh

Sent with AquaMail for Android
http://www.aqua-mail.com

[Matt McCutchen]

On Wed, 2015-10-21 at 22:50 +0800, mobileorg-android wrote:
> I'm at some pains to imagine how to handle it better than this (not that it
> matters, as I'm only a user, not a developer of this tool).

[...]

> This isn't an answer, but I hope at least an acknowledgment that
> mobileorg's current behavior is because it's a Difficult Problem.

I wouldn't let ourselves off the hook so easily. There's a simple (in
principle), complete solution that's consistent with the existing
design, which I would consider implementing in the future if it seems
like the difference matters to me or other people:

0. The mobile inbox is included in org-mobile-files.

1. The phone assigns a timestamp to each edit, and the computer stores
the timestamp of the last edit it has pulled in a special field in the
mobile inbox. So when the phone pulls a data set, it can tell which
edits are reflected in that data set.

2. After pushing an edit, the phone keeps the edit in the database until
it pulls a data set reflecting the edit.

3. Each time the phone pulls a data set, it locally reapplies all edits
it has that are not already reflected in the data set. Any edits that
fail to apply are added locally to the mobile inbox. (This would
essentially require duplicating the logic from org-mobile-apply.) This
way, the bodies of all conflicted edits remain available on the phone in
the mobile inbox, whether or not the edits have made the round trip to
the computer yet.

Matt