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 2 data that **must** be stored |
14 There is two critical data that **must** be stored in an obsolete Marker. |
15 |
15 |
16 :object: |
16 :object: |
17 the old obsoleted changeset |
17 the old obsoleted changeset |
18 |
18 |
19 :subjects: |
19 :replacements: |
20 list of new changeset. **must** accept 0, 1 or 2 element at least. Shall it |
20 list of new changeset. list size can be anything, including 0 (0..N) |
21 accept more than three ? |
21 |
|
22 Everybody agreed on this point. |
|
23 |
|
24 --- |
22 |
25 |
23 This is probably a good idea to have an unique Identifier, for UI, transfert and |
26 This is probably a good idea to have an unique Identifier, for UI, transfert and |
24 access. |
27 access. |
25 |
28 |
26 :id: same as changeset but for marker. |
29 :id: same as changeset but for marker. |
27 |
30 |
|
31 The field below will depends of the way we exchange obsolete marker betwenn |
|
32 changeset. |
|
33 |
|
34 --- |
|
35 |
28 Having audit data will be very usefull. When it get messy you need all the |
36 Having audit data will be very usefull. When it get messy you need all the |
29 information you can to understand the situation. (could be a group level) |
37 information you can to understand the situation. |
|
38 |
|
39 I have the felling that we are versionning history. Therefor we will probably |
|
40 need the same kind of information than when versionning Files. |
30 |
41 |
31 :date: date of the marker creation |
42 :date: date of the marker creation |
32 |
43 |
33 :user: ui.username |
44 :user: ui.username |
34 |
45 |
39 :tool: the automated too that made this |
50 :tool: the automated too that made this |
40 |
51 |
41 :operation: Kind of rewritting operation that created the marker (delete, |
52 :operation: Kind of rewritting operation that created the marker (delete, |
42 update, split, fold, reordering) To help conflict resolution. |
53 update, split, fold, reordering) To help conflict resolution. |
43 |
54 |
44 Any other data ? |
55 Matt see this a "too complicated". I'll wait for him to meet a very hairy |
45 |
56 situation to agree that they are needed. |
46 Shall we store the marker alone or should be group them ? |
57 |
47 ````````````````````````````````````````````````````````````` |
58 Leaving the door open to any addition data is an option too. |
48 |
59 |
49 Several operation rewrite multiple changeset at once. It may make sense to group |
60 How shall we store Marker on disk |
50 marker in this case. |
|
51 |
|
52 This could be seen as the same improvement than the introduction of coherent |
|
53 "changesets" in Files version control. |
|
54 |
|
55 This would help exchange and undo. |
|
56 |
|
57 |
|
58 How shall we store Marker on disk (and in memory) ? |
|
59 ````````````````````````````````````````````````````````` |
61 ````````````````````````````````````````````````````````` |
60 |
62 |
|
63 Requirement |
|
64 ............. |
|
65 |
61 We need to quickly load the 'object' to know the "obsolete" set. |
66 We need to quickly load the 'object' to know the "obsolete" set. |
62 |
67 We need quick access by object and replacements to travels along the graph. |
63 We need quick access by object and subject. |
68 |
|
69 Common Part |
|
70 ............. |
|
71 |
|
72 The file is store in `.hg/store/obsmarkers`. It is a binary files: |
|
73 |
|
74 We probably need a Format Version Number somewhere |
|
75 |
|
76 I'll put it in `.hg/store/obsmarkers-version` |
|
77 |
|
78 Minimalistic proposal |
|
79 ......................... |
|
80 |
|
81 The core of a Marker will we stored as: |
|
82 |
|
83 * number of replacement (8-Bytes integer) |
|
84 * node id of the obsolete changeset (20-Bytes hash) |
|
85 * node id of replacement changeset (20-Bytes hash x number of remplacement) |
|
86 |
|
87 Version with ID |
|
88 ......................... |
|
89 |
|
90 This version add a node id computed from the marker content. It will be present |
|
91 *before* other data: |
|
92 |
|
93 * node id of the maker (20-Bytes hash) |
|
94 |
|
95 |
|
96 Version with Metadata proposal |
|
97 ............................... |
|
98 |
|
99 An extra files is used to old metadata (date, user, etc) `.hg/store/obs-extra`:. The format of this |
|
100 field is undefined yet. This will add the following field at the end of a marker |
|
101 |
|
102 * offset of the metadata in obs-extra (8-Bytes integer) |
|
103 |
64 |
104 |
65 How shall we exchange Marker over the Wire ? |
105 How shall we exchange Marker over the Wire ? |
66 ````````````````````````````````````````````````````````` |
106 ````````````````````````````````````````````````````````` |
67 |
107 |
68 We can have a lot of markers. We do not want to exchange data for the one we |
108 We can have a lot of markers. We do not want to exchange data for the one we |