Branching

[samuelstroschein]

We need branches to isolate work.

[samuelstroschein]

Sequences can be implemented in different ways opral/monorepo#3073 (comment). We need to check in UX testing how "branching" would be used to know what's the right way to implement sequence(s).

[samuelstroschein]

Three requirements that come to my mind:

1. UUIDs for branches to enable anonymous branches and avoid "renamed branch" problems
2. Optionally assign a name to a branch to invite collegues
3. "Copy changes from branch a to branch b" just works (no rebase, merge, whatever crap)

Branching Workflow Requirements Discussion

@niklas.buchfink @nils.jacobsen (fink) @jan.johannes @jannes.blobel (csv protoype) @martin.lysk1 do you have more/different requirements?

[samuelstroschein]

From the Fossil and Sqlite creator "not keeping the branch history is the main complaint"

(recommended watch from @martin.lysk1)

Richard Hipp - Git: Just Say No

[NilsJacobsen]

I feel like copy changes from one to another branch is introduced too early. Let's build a simple change proposal with branches first.

[samuelstroschein]

we have to first decide if we want to use the concept of commits or not

No commits used.

[samuelstroschein]

Big insight after a call with @jan.johannes and @martin.lysk1:

"A branch is a filter of changes that are currently applied".

The definition of a branch as a filter is a simple mental model, copying changes between branches is not needed (which should tremendously ease workflows), and makes the implementation in an initial version trivial.

Proposed implementation

Add a new table Branch

table Branch {
  id: UUID
  // optional name that a user can set
  name: string | null
  // the changes that are "in this branch" 
  // and currently applied
  change_ids = Set<Change>
}

Automatically insert the first branch ("main" branch)

{
  id: "<uuid>"
  name: "main", 
  change_ids: [<existing changes>]
}

Add a pointer to the currently active branch

Probably the ref table or a config somewhere else.

---

@jan.johannes @martin.lysk1 are we aligned on the proposed implementation?

PS the definition "A branch is a filter of currently applied changes" already hints optimization potential of only storing change ids in the branch that are applied, not every change id even if unapplied.

[samuelstroschein]

roughly yes, but dont think the propose exact structure is good.

Fine but please something fast to test out. I doesn't need to be optimized.

[martin-lysk]

I would go with the following table structure table

CREATE TABLE branch (
    id TEXT PRIMARY KEY DEFAULT (uuid_v4()),
    name TEXT -- name of the branch 
  ) strict;

CREATE TABLE branch_change_map (
    id TEXT NOT NULL, -- references the id of the branch table
    change_id TEXT NOT NULL -- change that belongs to the branch
  ) strict;

We will append changes during the lifetime of a branch - for main branch during the whole lifetime.
With your proposal @samuel.stroschein on a change we would need to read the branch record, deserialize it (an array with milions of ids) add the the change to the branch record and write it back to the db - for every branch that is interested in the given change.

I would add a separate table branch_change_map to track the link between banches and changes as we outlined yesterday - a insert in to the change will just lead to an insert in the branch change map.

Also indexing which change belongs to wich branch will be - just adding a n index

[samuelstroschein]

I think our proposals are identical. Set<Change> was a reference to a table that stores what changes are active for a branch. It seems like that's what you are doing with branch_change_map. I was not proposing to use a serialized set. Sorry for the misunderstanding :D

Follow up:

1. a branch table has branch in the name already branch.branch_name is odd. i would go with branch.name

CREATE TABLE branch (
    id TEXT PRIMARY KEY DEFAULT (uuid_v4()),
-    branch_name TEXT
+    name TEXT -- name of the branch 
  ) strict;

2. Is the branch_change_map.id a foreign key to branch(id) ?
   1. if yes, why does it have a default value that generated a new uuid?
   2. if no, what's the id for? how is mapping to a branch established?

[martin-lysk]

1. sure
2. changed my comment

[samuelstroschein]

Aligned!

1. I propose to add the foreign keys to the schema already to make clear what is referenced. SQlite will not enforce the foreign keys until we turn LIXDK-134 on.
2. I would rename id to branch_id to make the reference to branch id clear.

Agree?

CREATE TABLE branch_change_map (
- id TEXT NOT NULL,
+ branch_id TEXT NOT NULL,
  change_id TEXT NOT NULL,
+ FOREIGN KEY (branch_id) REFERENCES branch(id),
+ FOREIGN KEY (change_id) REFERENCES change(id),
+ PRIMARY KEY (branch_id, change_id)
  ) strict;