Merging branches

Option 1:

Use the stored SQL commands from the source branch and run them in the destination branch.

Problem: if a previous merge was already done (from previous or the same commit)

Solution 1: use the SQL commands starting at the last merge

This implies storing merge info/history.

Pros:

• Easy to implement

Cons:

• No conflict detection
• Merging can take a long time to be processed if the SQL commands are complex (because they are re-executed)

---

Option 2:

Compare all the rows from source and destination branches.

Detect duplicated and modified rows as conflicts that must be resolved in some way.

Rows that exist on source but not on the destination should be copied to the destination without question (not a conflict).

Pros:

• Conflict detection
• Maybe faster at the merge stage

Cons:

• Maybe slower at the scan stage

---

Option 3:

Use the Session / Changeset feature

Pros:

• Conflict detection

Cons:

• Does not deal with schema differences
• SQL based, so merging can be slow on complex SQL commands

---

Option 4:

Use a modified Session / Changeset feature with these changes:

1. Detect schema differences

2. Copy rows directly instead of generating SQL commands

Pros:

• Conflict detection
• Deals with schema differences

Cons:

• Maybe hard to implement

---

Option 5:

Just like option 4 but automatically choosing the best / faster merge approach (run SQL or copy rows directly)

Pros:

• Conflict detection
• Deals with schema differences

Cons:

• Maybe hard to implement

---

Copying rows "directly"

Either by:

1. Using our code in C

2. Using the SQLite VDBE

Notice that the SQL commands from option 1 come from the log / history and the others are generated by code. So the complexity and speed of execution may vary a lot.

---

Notes

(you can add your notes here bellow or participate in the discussion here)