Introduce concept of change sets

[samuelstroschein]

@samuel.stroschein said in LIXDK-158:

Interesting observation:

Grouping changes is desired for branches, discussions, and now change tags. Every concept is re-implementing grouping changes. That is not only redundant but also violates the lix design principle "one concept, one purpose".

• The purpose of discussions is to discuss changes.
• The purpose of tags is to query the history.
• (The purpose of a branch is to filter applied changes) UNSURE if branches benefit from a generalized change set concept.

To reduce redundancies and obey to "one concept, one purpose", we should consider introducing a concept of "grouping changes". A discussion and tag point to a set of changes. If branches would benefit from a generalized concept is TBD after LIXDK-126 is introduced.

-CREATE TABLE discussion_change_map
-CREATE TABLE tag_change_map
-CREATE TABLE branch_change_map

+CREATE TABLE change_set

Enabled use cases

Change sets can enable various use cases besides discussions and tags that we are already aware of:

• release notes/change logs (they point to a set of changes too)
• tagging and discussion the same change set (instead of creating duplicate change sets for the tag and the discussion that both point to the same set of changes)
• …

Tasks

• refactor createDiscussion( changeIds ) -> createDiscussion( changeSetId )

[samuelstroschein]

@martin.lysk1 @jan.johannes no action required. I don't want to de-rail LIXDK-126. Get branching out, then we can optimize. Except, if you deem change sets already applicable for branching and see no barrier for generalization.

EDIT: To clarify, branching might not be influenced by change sets but change sets might be of value for tags, discussions, release notes, etc.