There are different ways to merge two entries. To minimize information loss, the merging is done on a field-per-field basis. Several things can happen:
Both fields are identical or both fields are not set. This is trivial.
A field is set in one version but not the other. The server verison could be kept, or the client version. Just keeping this field ensures minimal data loss.
A field is set in both the client and server version. There is no way of automatically detecting which one to keep. The server or the client version could be kept.
The best solution to this problem would be to keep a modify timestamp for each data field. Unfortunately this would need way to much memory on thin clients. Even on servers this would greatly increase overhead. So we have to find another way:
It is not so obvious how this situation could be handeld. To decide on which version to keep we will take a look the this example first: A server has synchronized with two different clients. All three contain equivalent data records:
Table 7.1. Merge example setup
| Data | Client A | Server | Client B |
|---|---|---|---|
| FN | Max Berger | Max Berger | Max Berger |
| Ermail;Internet | max@xslt.de | max@xslt.de | max@xslt.de |
| Phone;Work | 089 / 289 2xxxx | 089 / 289 2xxxx | 089 / 289 2xxxx |
| REV | 01/01/02 | 01/01/02 | 01/01/02 |
Now the data gets changed on both clients:
Table 7.2. Modified data
| Data | Client A | Server | Client B |
|---|---|---|---|
| FN | Max Berger | Max Berger | Max Berger |
| Email;Internet | m@xslt.de | max@xslt.de | max@xslt.de |
| Phone;Work | 089 / 289 2xxxx | 089 / 289 2xxxx | 089 / 289 1yyyy |
| REV | 02/02/02 | 01/01/02 | 03/03/02 |
Then client A synchronizes. The data has not changed on the server. So no conflict occurs, the server keeps the new data from client A:
Table 7.3. Client A has synchronized
| Data | Server | Client B |
|---|---|---|
| FN | Max Berger | Max Berger |
| Email;Internet | m@xslt.de | max@xslt.de |
| Phone;Work | 089 / 289 2xxxx | 089 / 289 1yyyy |
| REV | 02/02/02 | 03/03/02 |
When client B synchronizes, a conflict occurs and the data has to be merged. It is up to the server to decide which version to keep. For illustration, we will show both:
Table 7.4. Data after merge
| Data | Server keeping own version | Server keeping client version | Client B |
|---|---|---|---|
| FN | Max Berger | Max Berger | Max Berger |
| Email;Internet | m@xslt.de | max@xslt.de | max@xslt.de |
| Phone;Work | 089 / 289 2xxxx | 089 / 289 1yyyy | 089 / 289 1yyyy |
| REV | 02/02/02 | 03/03/02 | 03/03/02 |
Although some modifications get lost, it seems better to keep the server version. We do not know how much time has passed between both synchronizations. Other clients might have synchronized inbetween. Keeping the client version would allow the client to overwrite data with an old version.