1
2
3
4
5
6
7
|
Random thoughts:
* Changes to manifest to support:
+ Trees of wiki pages and tickets
+ The ability to cap or close a branch
+ See "Extended Manifests" below
|
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
Possible ticket file format:
"Ticket"
title: TEXT
ticketid: TEXT
exists-in: BASELINE -- 0 or more
fixed-in: BASELINE -- 0 or more
tag: TAG -- 0 or more
created: DATETIME
attachment: FILENAME DESCRIPTION
parent: UUID*
derived-from: TICKET-FILENAME
description: MULTILINE-TEXT
remarks: MULTILINE-TEXT
* Things handles with tags:
created-by
assigned-to
priority
severity
target-release
status
resolution
type
subsystem
Wiki header format:
"WikiPage"
parent: UUID*
title: TEXT
pagename: TEXT
mode: (readonly|appendonly|readwrite)
attachment: UUID name description
* Header ends with a blank line. wiki content follows.
Cluster format:
"Cluster"
(UUID\n)+
* Cluster generated in server mode only.
* Embargo cluster that reference phantoms or other embargoed clusters.
* Never send or ihave an embargoed cluster
New sync algorithm based on clusters:
* Keep a table of unclustered artifacts. Strive to keep this table
less than 100 entries.
* Client sends content of unclustered table as ihaves to server
* Server builds a new cluster if size of cluster table >100.
* Server sends unclustered table to client
* Server sends gimme for all unknown ihave received from client
* Client sends gimme for all unknown ihave received from server
* Previous two steps repeat until no more gimmes
Details of new push algorithm:
* Table "unsent" contains all files never pushed
* TEMP table "wanted" contains files the server does not have
Loop:
* Client sends login and "push" record
* Client sends file message for all files in unsent and removes
those files from the table.
* Client sends file message for all files in wanted.
* Client sends ihave messages for each entry in unclustered
------
* Server receives file message
* Server creates phantoms for unknown ihaves
* Server sends gimme messages for all phantoms
------
* For each gimme message add an entry to wanted
* Halt if the wanted table is empty
Details on new pull algorithm:
Loop:
* Client sends login and "pull" record
* Client sends "prior" message with repository id and max record number
* Client sends "gimme" for each phantom
--------
* Server creates new clusters to get unclustered size below 100
* If there is "prior" message with repository id that matches this
server, then send file messages for all record ids greater than
prior
* Server sends ihave messages for each entry in unclustered
* Server sends maxrid message
--------
* Client receives file records
* Client creates phantoms for unknown ihaves
* If no phantoms exist, record maxrid for the server and halt
Need a dephantomize algorithm
Auxiliary tables needed for new sync algorithm:
* unsent: files that have never been sent to another repository
* unclustered: non-phantom files not mentioned by a cluster
Random thoughts:
* Changes to manifest to support:
+ Trees of wiki pages and tickets
+ The ability to cap or close a branch
+ See "Extended Manifests" below
|