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. + +
