1 |
|
2 .. warning:: This document is still in heavy work in progress |
|
3 |
|
4 ----------------------------------------------------- |
|
5 Various technical details |
|
6 ----------------------------------------------------- |
|
7 |
|
8 Some stuff that worse to note. some may deserve their own section later. |
|
9 |
|
10 storing old changeset |
|
11 `````````````````````` |
|
12 |
|
13 The new general delta format allow a very efficient storage of two very similar |
|
14 changesets. Storing obsolete childrens using general delta takes no more place |
|
15 than storing the obsolete diff. Reverted file will even we reused. The whole |
|
16 operation will take much less space the strip backup. |
|
17 |
|
18 |
|
19 Abstraction from history rewriting UI |
|
20 ``````````````````````````````````````````` |
|
21 |
|
22 How Mercurial handle obsolete marker is independent from who decide to create |
|
23 them and what actual operation solve error case. Any of the existing history |
|
24 rewriting UI (rebase, mq, histedit) can lay obsolete marker and resolve |
|
25 situation created by other. To go further a hook system of obsolete marker |
|
26 creation would allow each mechanism to collaborate with other though a standard |
|
27 and central mechanism. |
|
28 |
|
29 |
|
30 Obsolete marker storage |
|
31 ``````````````````````````` |
|
32 |
|
33 Obsolete marker will most likely be stored outside standard history. They are |
|
34 multiple reasons for that: |
|
35 |
|
36 |
|
37 First, obsolete markers are really perpendicular to standard history there is not |
|
38 strong reason to include it here other than convenience. |
|
39 |
|
40 Second, storing obsolete marker inside standard history means: |
|
41 |
|
42 |
|
43 * A changeset must be created every time an obsolete relation is added. Very |
|
44 inconvenient for delete operation. |
|
45 |
|
46 * Obsolete marker must be forged at the creation of the new changeset. This |
|
47 is very inconvenient for split operation. And in general it become |
|
48 complicated to fix history afterward in particular when working with older |
|
49 client. |
|
50 |
|
51 Storing obsolete marker outside history have several pro: |
|
52 |
|
53 * It ease Exchange of obsolete marker without unnecessary obsolete changeset content |
|
54 |
|
55 * It allow tuning the actual storage and protocol exchange while maintaining |
|
56 compatibility with older client through the wire (as we do the repository |
|
57 format) |
|
58 |
|
59 * ease the exchange of obsolete related information during discovery to exchange |
|
60 obsolete changeset relevant to conflict resolution. Exchanging such |
|
61 information deserve a dedicated protocol. |
|
62 |
|
63 Persistent |
|
64 ``````````````````````` |
|
65 |
|
66 *Extinct* changeset and obsolete marker will most likely be garbage collected as |
|
67 some point. However, archive server may decide to keep them forever in order to |
|
68 keep a fully auditable history in it's finest conception. |
|
69 |
|
70 |
|
71 ----------------------------------------------------- |
|
72 Current status |
|
73 ----------------------------------------------------- |
|
74 |
|
75 An experimental implementatione exists. What have been done so far. |
|
76 |
|
77 |
|
78 * 1-1 obsolete marker stored outside history, |
|
79 |
|
80 * compute obsolete-tip |
|
81 |
|
82 * obsolete marker exchange through pushkey, |
|
83 |
|
84 * compute obsolete, unstable, extinct and suspended set. |
|
85 |
|
86 * hidden extinct changesets for UI. |
|
87 |
|
88 * Use secret phase to remove from discovery obsolete and unstable changeset (to |
|
89 be improved soon) |
|
90 |
|
91 * alter rebase to use obsolete marker instead of stripping. (XXX break --keep for now) |
|
92 |
|
93 * Have an experimental mq-like extension to rewrite history (more on that later) |
|
94 |
|
95 * Have an extension to update and mq repository according evolution of standard (more on that later) |
|
96 |
|