|
Size: 1192
Comment: initial description of in-memory merge plan
|
← Revision 3 as of 2017-12-06 21:36:57 ⇥
Size: 1350
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
See InMemoryMergePlan2 |
|
| Line 29: | Line 31: |
| * {X} have an experimental option to use in memory merge for rebase (& co), | |
| Line 30: | Line 33: |
| * {X} turn on memory rebase (& co) on by default, |
|
| Line 32: | Line 37: |
| CategoryDeveloper CategoryNewFeatures | CategoryDeveloper CategoryOldFeatures |
Note:
This page is primarily intended for developers of Mercurial.
In-Memory Merge
Status: Project
Main proponents: Sean Farley (smf)
![/!\](/moin-static/modernized/img/alert.png "/!\"){kind=small}
This is a speculative project and does not represent any firm decisions on future behavior.
Following up on my previous Google Summer of Code (2013), I plan to finish implementing in-memory merge. This will allow a full merge, in-memory, without needed to change the working directory. The benefits of this are many but most notably is a large speed-up for rebase and the ability to preview a merge.
1. Goal
Pretty sparse right now. See below for more info.
2. Detailed description
There are some bumps in the road that will need some thinking. Things such as conflicts, large files, etc.
3. Roadmap
abstract context object to handle writing of files (smf has code, see next item) - Un-bitrot smf's old branch
- refactor three way merge to use context objects instead of working dir
- seriously, refactor three way merge to use context objects instead of working dir
- have an experimental option to use in memory merge for rebase (& co),
- implement a clean fallback to disk (large files, conflicts, etc.)
- turn on memory rebase (& co) on by default,