4 ms·

I would assume every diff has a timestamp. And since you can diff properties separately then it works correctly. I would be curious about another scenario: wha

I would assume every diff has a timestamp. And since you can diff properties separately then it works correctly. I would be curious about another scenario: what about several devices generating a new password for a website? Or instead - creating a note with the same name? The one that is going to be saved is the last one - that is true. But it implies there's some transparent data loss in the background (you could still get those from the log, of course). How do you deal with those "soft" conflicts in the UI? Is there any learning curve for the user to accept that any changes could be rolled back? How do you display that so that the user wouldn't assume the data was lost?

Normal_gaussian 8y ago
With respect to the notes of the same name - you can key the items with a generated id and "namespace" the keys with a journal specific id to avoid conflicts. In this way two notes having the same name is 'ok' as they have different keys. It would help to have a user guided merge feature that can be manually triggered by combining items (not just on conflict)
- allenu 8y ago
  This is exactly what I'm doing with my solution.
allenu 8y ago
With my system, I create a UUID for each entry, so I'm guaranteed uniqueness there. The other properties (task name) can be whatever you want. You're right that it gets even more tricky if you are doing key=>value pairs and are expecting that the key is something that may not be unique across devices (i.e. two devices using the same website domain as they key would lead to a conflict).
jayd16 8y ago
Hmm, something nice about this change log solution is that merge is built in by design. You could very happily default to all new collection items start with a UUID despite things like user definable item names. Normally this might be annoying but with merge as a first class citizen its easy to add a "merge these items" feature. Not only is there no hidden data loss, but it also adds the nifty feature of being able to merge totally unique item.

Normal_gaussian 8y ago

With respect to the notes of the same name - you can key the items with a generated id and "namespace" the keys with a journal specific id to avoid conflicts. In this way two notes having the same name is 'ok' as they have different keys. It would help to have a user guided merge feature that can be manually triggered by combining items (not just on conflict)

allenu 8y ago
This is exactly what I'm doing with my solution.

allenu 8y ago

With my system, I create a UUID for each entry, so I'm guaranteed uniqueness there. The other properties (task name) can be whatever you want. You're right that it gets even more tricky if you are doing key=>value pairs and are expecting that the key is something that may not be unique across devices (i.e. two devices using the same website domain as they key would lead to a conflict).

jayd16 8y ago

Hmm, something nice about this change log solution is that merge is built in by design. You could very happily default to all new collection items start with a UUID despite things like user definable item names. Normally this might be annoying but with merge as a first class citizen its easy to add a "merge these items" feature. Not only is there no hidden data loss, but it also adds the nifty feature of being able to merge totally unique item.