168 |
168 |
169 Conflicting history rewriting operation can be detected and **resolved** as easily |
169 Conflicting history rewriting operation can be detected and **resolved** as easily |
170 as conflicting changes on file. |
170 as conflicting changes on file. |
171 |
171 |
172 |
172 |
173 Detecting and solving tricky situation |
173 Detecting and solving tricky situations |
174 ====================================== |
174 ====================================== |
175 |
175 |
176 History rewriting can lead to complex situations. Obsolete marker introduce a |
176 History rewriting can lead to complex situations. Obsolete marker introduce a |
177 simple representation of this complex reality. But people using complex workflows |
177 simple representation of this complex reality. But people using complex workflows |
178 will one day or another have to face the intrinsic complexity of some |
178 will one day or another have to face the intrinsic complexity of some |
231 Proper warning should be issued when part of the history become unstable. UI |
231 Proper warning should be issued when part of the history become unstable. UI |
232 will be able to use the obsolete marker to automatically suggest resolution to |
232 will be able to use the obsolete marker to automatically suggest resolution to |
233 the user of even carry them out for him. |
233 the user of even carry them out for him. |
234 |
234 |
235 |
235 |
236 XXX details automatic resolution for |
236 XXX details on automatic resolution for |
237 |
237 |
238 * movement |
238 * movement |
239 |
239 |
240 * handling deletion |
240 * handling deletion |
241 |
241 |
242 * handling split on multiple head |
242 * handling split on multiple head |
243 |
243 |
244 |
244 |
245 .. [#] For this to happen one needs to explicitly enable exchange of draft |
245 .. [#] For this to happen one needs to explicitly enable exchange of draft |
246 changeset. See phase help for details. |
246 changesets. See phase help for details. |
247 |
247 |
248 The two part of the obsolete set |
248 The two part of the obsolete set |
249 -------------------------------- |
249 -------------------------------- |
250 |
250 |
251 The previous section show that it could be two kinds of *obsolete* changeset: |
251 The previous section show that there can be two kinds of an *obsolete* changeset: |
252 |
252 |
253 |
253 |
254 * *obsolete* changeset with no or *obsolete* only descendants, said **extinct**. |
254 * an *obsolete* changeset with no or *obsolete* only descendants is called **extinct**. |
255 |
255 |
256 * *obsolete* changeset with *unstable* descendants, said **suspended**. |
256 * an *obsolete* changeset with *unstable* descendants is called **suspended**. |
257 |
257 |
258 |
258 |
259 .. figure:: ./figures/error-extinct.* |
259 .. figure:: ./figures/error-extinct.* |
260 |
260 |
261 Amend `A` and `C` leaving `B` behind. |
261 Amend `A` and `C` leaving `B` behind. |
264 children is *extinct*. `A` with *unstable* descendant (`B`) is *suspended*. |
264 children is *extinct*. `A` with *unstable* descendant (`B`) is *suspended*. |
265 `B` is *unstable* as before. |
265 `B` is *unstable* as before. |
266 |
266 |
267 |
267 |
268 Because nothing outside the obsolete set default on *extinct* changesets, they |
268 Because nothing outside the obsolete set default on *extinct* changesets, they |
269 can be safely hidden in the UI and even garbage collected. *Suspended* changeset |
269 can be safely hidden in the UI and even garbage collected. *Suspended* changesets |
270 have to stay visible and available until they unstable descendant are rewritten |
270 have to stay visible and available until their unstable descendant are rewritten |
271 in stable version. |
271 into stable version. |
272 |
272 |
273 |
273 |
274 Conflicting rewriting |
274 Conflicting rewrites |
275 --------------------- |
275 --------------------- |
276 |
276 |
277 If people start to concurrently edit the same part of the history they will |
277 If people start to concurrently edit the same part of the history they will |
278 likely meet conflicting situation when a changeset have been rewritten in two |
278 likely meet conflicting situations when a changeset has been rewritten in two |
279 different versions. |
279 different ways. |
280 |
280 |
281 |
281 |
282 .. figure:: ./figures/error-conflicting.* |
282 .. figure:: ./figures/error-conflicting.* |
283 |
283 |
284 Conflicting rewriting of `A` into `A'` and `A''` |
284 Conflicting rewrite of `A` into `A'` and `A''` |
285 |
285 |
286 This kind of conflict is easy to detect with obsolete marker because an obsolete |
286 This kind of conflict is easy to detect with obsolete markers, because an obsolete |
287 changeset have more than one new version. It may be seen as the multiple heads |
287 changeset can have more than one new version. It may be seen as the multiple heads |
288 case Mercurial warn you about on pull. It is resolved the same way by a merge of |
288 case which Mercurial warns you about on pull. It is resolved the same way by a merge of |
289 A' and A'' that will keep the same parent than `A'` and `A''` with two obsolete |
289 A' and A'' that will keep the same parent than `A'` and `A''` with two obsolete |
290 markers pointing to both `A` and `A'` |
290 markers pointing to both `A` and `A'` |
291 |
291 |
292 .. warning:: TODO: Add a schema of the resolution. (merge A' and A'' with A as |
292 .. warning:: TODO: Add a schema of the resolution. (merge A' and A'' with A as |
293 ancestor and graft the result of A^) |
293 ancestor and graft the result of A^) |
294 |
294 |
295 Allowing multiple new changesets to obsolete a single one allow to distinct a |
295 Allowing multiple new changesets to obsolete a single one allows to differenciate |
296 splitted changeset from history rewriting conflict. |
296 split changesets from history rewriting conflicts. |
297 |
297 |
298 Reliable history |
298 Reliable history |
299 ---------------- |
299 ---------------- |
300 |
300 |
301 Obsolete marker really help to smooth rewriting operation process. However they |
301 Obsolete marker help to smooth rewriting operation process. However they |
302 do not change the fact that **you should only rewrite the mutable part of the |
302 do not change the fact that **you should only rewrite the mutable part of the |
303 history**. The phase concept enforce this rules by explicitly defining a |
303 history**. The phase concept enforces this rule by explicitly defining a |
304 public immutable set of changeset. Rewriting operation refuse to work on |
304 public immutable set of changesets. Rewriting operations refuse to work on |
305 public changeset, but they is still some corner case where changesets |
305 public changesets, but there are still some corner cases where previously rewritten changesets |
306 rewritten in the past are made public. |
306 are made public. |
307 |
307 |
308 Special rules apply for obsolete marker pointing to public changeset |
308 Special rules apply for obsolete markers pointing to public changesets |
309 |
309 |
310 * Public changesets are excluded from the obsolete set (public changeset are |
310 * Public changesets are excluded from the obsolete set (public changeset are |
311 never hidden or candidate to garbage collection) |
311 never hidden or candidate to garbage collection) |
312 |
312 |
313 * *newer* version of public changeset are said **latecomer** and highlighted as |
313 * *newer* version of public changeset are said **latecomer** and highlighted as |
323 |
323 |
324 |
324 |
325 Conclusion |
325 Conclusion |
326 ========== |
326 ========== |
327 |
327 |
328 Obsolete marker is a powerful concept that allow mercurial to safely handle |
328 The obsolete marker is a powerful concept that allows mercurial to safely handle |
329 history rewriting operations. It is a new type of relation between Mercurial |
329 history rewriting operations. It is a new type of relation between Mercurial |
330 changesets that track the result of history rewriting operations. |
330 changesets which tracks the result of history rewriting operations. |
331 |
331 |
332 This concept is simple to define and provides a very solid base to: |
332 This concept is simple to define and provides a very solid base for: |
333 |
333 |
334 |
334 |
335 - Very fast history rewriting operations, |
335 - Very fast history rewriting operations, |
336 |
336 |
337 - auditable and reversible history rewriting process, |
337 - auditable and reversible history rewriting process, |
338 |
338 |
339 - clean final history, |
339 - clean final history, |
340 |
340 |
341 - share and collaborate on mutable part of the history, |
341 - sharing and collaborating on the mutable part of the history, |
342 |
342 |
343 - gracefully handle history rewriting conflict, |
343 - gracefully handling history rewriting conflicts, |
344 |
344 |
345 - allows various history rewriting UI to collaborate with a underlying common API. |
345 - various history rewriting UI’s collaborating with an underlying common API. |
346 |
346 |
347 .. list-table:: Comparison on solution [#]_ |
347 .. list-table:: Comparison on solution [#]_ |
348 :header-rows: 1 |
348 :header-rows: 1 |
349 |
349 |
350 * - Solution |
350 * - Solution |