| Summary | Allow SyncML conflict resolution by duplication |
| Queue | Synchronization |
| Queue Version | Git master |
| Type | Enhancement |
| State | Assigned |
| Priority | 1. Low |
| Owners | wrobel (at) horde (dot) org |
| Requester | wrobel (at) horde (dot) org |
| Created | 04/28/2008 (6225 days ago) |
| Due | |
| Updated | 10/24/2010 (5316 days ago) |
| Assigned | 01/12/2009 (5966 days ago) |
| Resolved | |
| Milestone | |
| Patch | No |
Patch ⇒ No
Taken from Jan Schneider
State ⇒ Assigned
assign it to me so that I have it on my long term ToDo list?
Taken from Karsten Fourmont
State ⇒ Feedback
implementation. Reason is, that it does yet another request to the
backend for every single client change. Synchronization already puts a
high load on the backend and I don't want to even worse it. Especially
since we retrieve the information about server changes anyway, at
least during two-way-syncs.
That's another point, only two-way-syncs can create conflicts, so we
should only check for them in this case. OTOH, we only retrieve both
server and client changes in two-way-syncs, so it might be sufficient
to simply compare them.
New Attachment: HK-GW-SyncML_conflicts[1].patch
Assigned to Karsten Fourmont
New Attachment: HK-GW-SyncML_conflicts.patch
State ⇒ New
Patch ⇒ No
Milestone ⇒
Queue ⇒ Synchronization
Summary ⇒ Allow SyncML conflict resolution by duplication
Type ⇒ Enhancement
Priority ⇒ 1. Low
edited on both the server and the client since the last
synchronization) with "first synchronization wins". This means the
client will usually overwrite any modifications done on the server as
the client usually synchs first during a synchronization run.
The attached patch will respond to such conflicts with a duplication
of the conflicting element. I believe this is preferable over possible
data loss. If necessary it could also be made configurable.