[Subversion Wiki] Update of "MergeDev/DataModel" by StefanFuhrmann

[Apache subversion Wiki <co...@subversion.apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "MergeDev/DataModel" page has been changed by StefanFuhrmann:
http://wiki.apache.org/subversion/MergeDev/DataModel?action=diff&rev1=4&rev2=5

   1. diagrams are yet to follow
  
   2. many aspects are not modelled correctly and will change
-     to whatever further discussion will suggest
+  to whatever further discussion will suggest
  
  
  == Entities ==
@@ -27, +27 @@

  by the user. Due guarantee referential integrity, there is no way
  to delete an atomic change.
  Attributes: ID (relative to revision), change type, path, node type,
-             optional: copyfrom path + rev
+ optional: copyfrom path + rev
  
  Change types:
   * no-op (instead of deletion; also for merges that result in zero net change)
@@ -50, +50 @@

  along the merge hierarchy.
  
  
+ 
  == Operations ==
  
  
+ == Notes from Discussions ==
  
+  * Merged changes within the same merged change list may cancel each other out.
+  We still need to record all of them.
+  * We need to represent undo and blocking merges
+  * Operations should be simple
+  * There will be different path matching strategies being applied in the following
+  order: last merge, latest common ancestor, (relative) path name.
+  * Merge history and "natural" history should be treated (somewhat) uniformly.
+  Thus, we may want a common path mapping index for that. So, store the base path
+  of every merge.
+  * What is the semantics of "undo merges" from before the latest common ancestor?
+  * Ability to mark change as "irrelevant" for future merges.
+  * The info about blocked merges is part of HEAD. We record the actual merge
+  decisions when they happen. "Block" will only filter future merges and *might*
+  be a basis to suggest undo merges.
+  * Merges between "mismatched" sub-paths establish a new path mapping relationship
+  by default (user may override). Rationale: the merge went through, probably with
+  some conflicts left to resolve, and the user committed the result. It's no longer
+  a mere accident in the mayority of cases.
  
  = Internal Data Model =
  
+ == Notes from Discussions ==
+ 
+  * Lists of merged changes may have significant overlap, e.g. when sync'ing
+  multiple branches with /trunk. We should represent them as lists of shared
+  sub-lists.
+  * Having a copy-only sub-set of the history will minimize the sheer amount
+  of data to be processed. Possibly, some extra indexing on that separate
+  storage may add to its usefulness.
+  * Indexing the merge data model: Since this can be written / modified after
+  the fact, having a tight representation may be difficult. However, we use
+  have some revision-related storage such as a few extra files to a pack file.
+  Rationale: once the relevant range of history has been identified by path
+  mapping, all further operations can be related to revisions or ranges of
+  revisions.
+ 
  = External Data Model =
  
+ == Notes from Discussions ==
+ 
+  * How do undo merges work retroactively?
+  * Diff'ing and combining change lists and merges is part of the external model
+  (respectively its operations)
+  * There is a significant difference between "revert" (undo the effects of
+  a merge in the working copy) and "resolve" (take whatever the current w/c
+  state is for the result of the merge). That's a UI / user awareness issue.
+  * Splits and joins are not modelled explicitly. For many typical cases,
+  however, conflict resolution strategies may be provided that cover them
+  nicely without adding complexity to the data model.
+  
+