First sync on tomdroid fails because of wrong LATEST_SYNC_REVISION

Bug #1074676 reported by McFry
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Tomdroid
Fix Released
Medium
Unassigned
Beta
Fix Released
Medium
Unassigned

Bug Description

In file http://bazaar.launchpad.net/~tomdroid-maintainers/tomdroid/note-editing-and-syncing/view/head:/src/org/tomdroid/util/Preferences.java#L61

(line 61):
LATEST_SYNC_REVISION ("latest_sync_revision", 0L),

The LATEST_SYNC_REVISION is a global revision counter for the whole note repository and seems to be initialized to 0 in the file given above. When syncing with a server for the very first time, this value should be -1 instead of 0.

Tomboy on linux also uses -1 as initial value, as one can see when opening the manifest.xml from tomboy before any syncing was done.

Because of the initial value of 0, I can reproduce a failed sync in the following scenario:

Set Tomboy to sync with the server for the very first time and initially send some notes -> The LATEST_SYNC_REVISION counter is increased from -1 to 0 on the server with this initial push.

Now when using tomdroid to PULL those notes, Tomdroid successfully connects, retrieves a list of notes (which need to be pulled), and receive a server-side LATEST_SYNC_REVISION value of 0. Since the tomdroid global LATEST_SYNC_REVISION is 0 too, no new notes are imported (because the remote repo is not newer (has higher LATEST_SYNC_REVISION) than the local one).

This bug does NOT appear if

a) you sync with tomboy fore more then 1 time before using tomdroid (as then the LATEST_SYNC_REVISION will be 1 or greater and tomdroids LATEST_SYNC_REVISION is 0, hence the server counter is higher)
b) you create a note in Tomdroid prior to pulling the notes, as the first note will have a _local_ "last-sync-revision" of 1, which will set the servers LATEST_SYNC_REVISION to at least 1

and hence isn't that obvious to find :)

My suggestion: Change the initial value of LATEST_SYNC_REVISION from 0 to -1, that should fix it.

Disclaimer: I am shooting into the dark here as I don't have an Android SDK and can't build the source, nor do I use Ubuntu1; all my assumptions are based on my work on an experimental new sync server, but which works currently for tomboy when doing 2way syncing. So please assure my suggestion do not break Ubuntu1 sync.

Revision history for this message
Stefan Hammer (j-4-deactivatedaccount) wrote :

Hi!

I set the last-sync-revision initialisation to:
LATEST_SYNC_REVISION ("latest_sync_revision", -1L),

Could you please try with your setup again and report back, if it is fixed now?! Pretty please :-D
Thanks a lot!

grab the build here again: http://goo.gl/#analytics/goo.gl/fKg6N/all_time

Changed in tomdroid:
milestone: none → 0.7.3
assignee: nobody → Stefan Hammer (j-4)
importance: Undecided → Medium
status: New → Triaged
Revision history for this message
McFry (timo-latecrew) wrote :

I grabbed the latest build and retest, but still doesn't work.

Setting server side sync revision is 0 (which means, the server has had a single note push from tomboy, hence increased his default value of -1 to 0), and then pairing tomdroid with the sync server on the first sync gives me in the aLogCat output:

V/SyncService( 9575): sync progress: 35
D/SnowySyncService( 9575): old latest sync revision: 0, remote latest sync revision: 0
V/SnowySyncService( 9575): old sync revision on server, cancelling
V/NoteManager( 9575): Deleted 0 local notes based on system:deleted tag
V/SyncService( 9575): sync progress: 100

So, the latestSyncRevision variable is still 0 at http://bazaar.launchpad.net/~tomdroid-maintainers/tomdroid/note-editing-and-syncing/view/head:/src/org/tomdroid/sync/web/SnowySyncService.java#L213

but i have no clue why this is?

I'Ve attached a full log from aLogcat.

Revision history for this message
Stefan Hammer (j-4-deactivatedaccount) wrote :

Just fixed this one!

grab the build here again for testing: http://goo.gl/#analytics/goo.gl/fKg6N/all_time

Changed in tomdroid:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.