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
|
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
|
-
+
-
+
-
+
-
+
+
-
+
+
|
Just thinking out loud...
Code reviews... might be implementable in terms of tags. A tag directly on a commit (or wiki page, for that matter) would be treated as a comment. A tag on another comment essentially creates a comment thread.
The question, really, is how to store such constructs.Some random ideas:
(...big, now irrelevant/obsolete, snip...)
So we store them as blobs with a new Control Artifact form. We can (at least in principal) introduce a new card type if it only appears in new artifact types.
So we store them as blobs with a new Control Artifact form. We can (at least in principal) introduce a new card type if it only appears in new artifact types and doesn't introduce an incompatibility with planned/foreseen card additions.
Hypothetical Comment (or Thread, or Opinion) Artifact:
<nowiki><pre>
D timestamp
C comment-text
U user
V uuid-being-tagged ?[-0+]? (default opinion==0)
V uuid-being-tagged/replied-to ?[-0+]? ("Opinion", default==0)
Z manifest-hash
</pre></nowiki>
'V' comes from reView. i'd prefer another letter - i suspect V has a better use in future versions of fossil. Maybe 'O' for "Opinion."
Then we add a tag just like a Ticket's:
Then we add a tag just like a Ticket's during crosslinking:
<nowiki><pre>
comment-UUID_OF_ARTIFACT
comment-UUID_OF_COMMENT_ARTIFACT
</pre></nowiki>
We could use the existing close tag to resolve/close reviews (e.g. for purposes of tracking review lifetimes/expirations/due-dates).
We could (i suspect) use the existing close tag to resolve/close reviews (e.g. for purposes of tracking review lifetimes/expiration/due-dates).
Hmmm. "It just might work."
We can potentially re-use a Control Artifact, leave out the "opinion" argument, and use T cards (compatible with current code):
<nowiki><pre>
T +thread-comment...
|