Mercurial > evolve

comparison docs/obs-implementation.rst @ 357:b398e9c2dbd1 stable

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
doc: English proofreading
author Jordi Gutiérrez Hermoso <jordigh@octave.org>
date Wed, 11 Jul 2012 13:59:06 -0400
parents 5eecfda0a5c7
children 9a17c48c2099
comparison
equal deleted inserted replaced
345:62de989b2a02 357:b398e9c2dbd1
9 9
10 10
11 What data should be contained in a Marker ? 11 What data should be contained in a Marker ?
12 ```````````````````````````````````````````````````` 12 ````````````````````````````````````````````````````
13 13
14 There is two critical data that **must** be stored in an obsolete Marker. 14 There are two critical pieces of information that **must** be stored
15 in an obsolete Marker.
15 16
16 :object: 17 :object:
17 the old obsoleted changeset 18 the old obsoleted changeset
18 19
19 :replacements: 20 :replacements:
21 22
22 Everybody agreed on this point. 23 Everybody agreed on this point.
23 24
24 --- 25 ---
25 26
26 This is probably a good idea to have an unique Identifier, for UI, transfert and 27 This is probably a good idea to have an unique Identifier, for UI, transfer and
27 access. 28 access.
28 29
29 :id: same as changeset but for marker. 30 :id: same as changeset but for marker.
30 31
31 The field below will depends of the way we exchange obsolete marker betwenn 32 The field below will depend on the way we exchange obsolete marker between
32 changeset. 33 changesets.
33 34
34 --- 35 ---
35 36
36 Having audit data will be very usefull. When it get messy you need all the 37 Having audit data will be very useful. When it gets messy you need all the
37 information you can to understand the situation. 38 information available to understand the situation.
38 39
39 I have the felling that we are versionning history. Therefor we will probably 40 I have the feeling that we are versioning history. Therefor we will probably
40 need the same kind of information than when versionning Files. 41 need the same kind of information than when versioning Files.
41 42
42 :date: date of the marker creation 43 :date: date of the marker creation
43 44
44 :user: ui.username 45 :user: ui.username
45 46
46 To go further: 47 To go further:
47 48
48 :description: "Optional reason for the rewrite (generated of added by the user)" 49 :description: "Optional reason for the rewrite (generated by the user)"
49 50
50 :tool: the automated too that made this 51 :tool: the automated tool that made this
51 52
52 :operation: Kind of rewritting operation that created the marker (delete, 53 :operation: Kind of rewritting operation that created the marker (delete,
53 update, split, fold, reordering) To help conflict resolution. 54 update, split, fold, reordering), to help conflict resolution.
54 55
55 Matt see this a "too complicated". I'll wait for him to meet a very hairy 56 Matt said this is "too complicated". I'll wait for him to meet a very hairy
56 situation to agree that they are needed. 57 situation to agree that they are needed.
57 58
58 Leaving the door open to any addition data is an option too. 59 Leaving the door open to any addition data is an option too.
59 60
60 How shall we store Marker on disk 61 How shall we store Marker on disk
93 94
94 95
95 Version with Metadata proposal 96 Version with Metadata proposal
96 ............................... 97 ...............................
97 98
98 An extra files is used to old metadata (date, user, etc) `.hg/store/obs-extra`:. The format of this 99 An extra files is used to old metadata (date, user, etc) `.hg/store/obs-extra`:.
99 field is undefined yet. This will add the following field at the end of a marker 100
101 The format of this field is undefined yet. This will add the following
102 field at the end of a marker
100 103
101 * offset of the metadata in obs-extra (8-Bytes integer) 104 * offset of the metadata in obs-extra (8-Bytes integer)
102 105
103 106
104 How shall we exchange Marker over the Wire ? 107 How shall we exchange Marker over the Wire ?
122 125
123 storing old changeset 126 storing old changeset
124 `````````````````````` 127 ``````````````````````
125 128
126 The new general delta format allows a very efficient storage of two very similar 129 The new general delta format allows a very efficient storage of two very similar
127 changesets. Storing obsolete childrens using general delta takes no more place 130 changesets. Storing obsolete children using general delta takes no more place
128 than storing the obsolete diff. Reverted file will even we reused. The whole 131 than storing the obsolete diff. Reverted file will even we reused. The whole
129 operation will take much less space the strip backup. 132 operation will take much less space the strip backup.
130 133
131 134
132 Abstraction from history rewriting UI 135 Abstraction from history rewriting UI
133 ``````````````````````````````````````````` 136 ```````````````````````````````````````````
134 137
135 How Mercurial handle obsolete marker is independent from who decide to create 138 How Mercurial handles obsolete marker is independent from what decides
136 them and what actual operation solve error case. Any of the existing history 139 to create them and what actual operation solves the error case. Any of
137 rewriting UI (rebase, mq, histedit) can lay obsolete marker and resolve 140 the existing history rewriting UI (rebase, mq, histedit) can lay
138 situation created by other. To go further a hook system of obsolete marker 141 obsolete markers and resolve situation created by others. To go
139 creation would allow each mechanism to collaborate with other though a standard 142 further, a hook system of obsolete marker creation would allow each
140 and central mechanism. 143 mechanism to collaborate with other though a standard and central
144 mechanism.
141 145
142 146
143 Obsolete marker storage 147 Obsolete marker storage
144 ``````````````````````````` 148 ```````````````````````````
145 149
146 Obsolete marker will most likely be stored outside standard history. They are 150 The Obsolete marker will most likely be stored outside standard
147 multiple reasons for that: 151 history. They are multiple reasons for this:
148 152
149 153 First, obsolete markers are really perpendicular to standard history
150 First, obsolete markers are really perpendicular to standard history there is not 154 there is no strong reason to include it here other than convenience.
151 strong reason to include it here other than convenience.
152 155
153 Second, storing obsolete marker inside standard history means: 156 Second, storing obsolete marker inside standard history means:
154
155 157
156 * A changeset must be created every time an obsolete relation is added. Very 158 * A changeset must be created every time an obsolete relation is added. Very
157 inconvenient for delete operation. 159 inconvenient for delete operation.
158 160
159 * Obsolete marker must be forged at the creation of the new changeset. This 161 * Obsolete marker must be forged at the creation of the new changeset. This
160 is very inconvenient for split operation. And in general it become 162 is very inconvenient for split operation. And in general it becomes
161 complicated to fix history afterward in particular when working with older 163 complicated to fix history afterward in particular when working with older
162 client. 164 clients.
163 165
164 Storing obsolete marker outside history have several pro: 166 Storing obsolete marker outside history have several pros:
165 167
166 * It ease Exchange of obsolete marker without unnecessary obsolete changeset content 168 * It eases Exchange of obsolete markers without unnecessary obsolete
167 169 changeset contents.
168 * It allow tuning the actual storage and protocol exchange while maintaining 170
169 compatibility with older client through the wire (as we do the repository 171 * It allows tuning the actual storage and protocol exchange while maintaining
170 format) 172 compatibility with older clients through the wire (as we do the repository
171 173 format).
172 * ease the exchange of obsolete related information during discovery to exchange 174
173 obsolete changeset relevant to conflict resolution. Exchanging such 175 * It eases the exchange of obsolete related information during
174 information deserve a dedicated protocol. 176 discovery to exchange obsolete changeset relevant to conflict
177 resolution. Exchanging such information deserves a dedicated
178 protocol.
175 179
176 Persistent 180 Persistent
177 ``````````````````````` 181 ```````````````````````
178 182
179 *Extinct* changeset and obsolete marker will most likely be garbage collected as 183 *Extinct* changeset and obsolete marker will most likely be garbage collected as
180 some point. However, archive server may decide to keep them forever in order to 184 some point. However, archive server may decide to keep them forever in order to
181 keep a fully auditable history in it's finest conception. 185 keep a fully auditable history in its finest conception.
182 186
183 187
184 Current status 188 Current status
185 ----------------------------------------------------- 189 -----------------------------------------------------
186 190
195 199
196 * compute obsolete, unstable, extinct and suspended set. 200 * compute obsolete, unstable, extinct and suspended set.
197 201
198 * hidden extinct changesets for UI. 202 * hidden extinct changesets for UI.
199 203
200 * Use secret phase to remove from discovery obsolete and unstable changeset (to 204 * Use secret phase to remove from discovery obsolete and unstable changesets (to
201 be improved soon) 205 be improved soon)
202 206
203 * alter rebase to use obsolete marker instead of stripping. 207 * alter rebase to use obsolete markers instead of stripping.
204 208
205 * Have an experimental mq-like extension to rewrite history (more on that later) 209 * Have an experimental mq-like extension to rewrite history (more on that later)
206 210
207 * Have an extension to update and mq repository according evolution of standard (more on that later) 211 * Have an extension to update and mq repository according evolution of
208 212 standard (more on that later)
213