Fossil SCM
Add notes about forked forum posts to www/forum.wiki so that future us will be reminded at some point to return to that topic.
Commit
22648d1832fb7a28f544366b02d04bc6e5d05a290a23f92c3d68fe6e9fa65020
Parent
8da3b3f796f88d9…
1 file changed
+42
+42
| --- www/forum.wiki | ||
| +++ www/forum.wiki | ||
| @@ -557,5 +557,47 @@ | ||
| 557 | 557 | rendering a preview wildly resizes the widget. The effect is |
| 558 | 558 | especially helpful when working on posts while the bottom footer of |
| 559 | 559 | the page is in the viewport, as the footer is a hard boundary against |
| 560 | 560 | scrolling. With the extra padding, the editor widget's top edge shifts |
| 561 | 561 | around less when the preview is shown and hidden. |
| 562 | + | |
| 563 | +<h2 name="fork">Forked Edits</h2> | |
| 564 | + | |
| 565 | +It is possible to "fork" forum messages, in the same way that any | |
| 566 | +given check-in may cause a fork. This can happen when a message is | |
| 567 | +edited concurrently from two or more browser tabs or via two or more | |
| 568 | +fossil instances which subsequently sync with each other. | |
| 569 | + | |
| 570 | +When a forum post is forked, the UI currently behaves as it does for | |
| 571 | +concurrent wiki page edits, showing only the most recent | |
| 572 | +edit. Currently (2026-06) the UI is incapable of showing the older | |
| 573 | +forked copies but (A) the data are still part of the SCM history and | |
| 574 | +(B) there are plans to improve the UI to show such forks. | |
| 575 | + | |
| 576 | +For trivia's sake, here's a query which finds posts which have | |
| 577 | +forks: | |
| 578 | + | |
| 579 | +<pre><verbatim> | |
| 580 | +SELECT bp.rid AS parentRid, bp.uuid parentUuid, count(f.fprev) forkCount | |
| 581 | +FROM blob b, blob bp, forumpost f | |
| 582 | +WHERE b.rid=f.fpid | |
| 583 | +AND f.fprev=bp.rid | |
| 584 | +GROUP BY f.fprev | |
| 585 | +HAVING forkCount>1; | |
| 586 | +</verbatim></pre> | |
| 587 | + | |
| 588 | +And here's one which lists forked posts: | |
| 589 | + | |
| 590 | +<pre><verbatim> | |
| 591 | +WITH multiparent(mpid) AS ( | |
| 592 | + SELECT fprev FROM forumpost f | |
| 593 | + GROUP BY fprev | |
| 594 | + HAVING count(fprev)>1 | |
| 595 | +) | |
| 596 | +SELECT datetime(fmtime), forumpost.* | |
| 597 | +FROM forumpost, multiparent | |
| 598 | +WHERE fprev=mpid | |
| 599 | +ORDER BY mpid, fpid, fmtime; | |
| 600 | +</verbatim></pre> | |
| 601 | + | |
| 602 | +The telling part is the <code>fprev</code> column: those with matching | |
| 603 | +values forked from the post referred to by <code>fprev</code>. | |
| 562 | 604 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -557,5 +557,47 @@ | |
| 557 | rendering a preview wildly resizes the widget. The effect is |
| 558 | especially helpful when working on posts while the bottom footer of |
| 559 | the page is in the viewport, as the footer is a hard boundary against |
| 560 | scrolling. With the extra padding, the editor widget's top edge shifts |
| 561 | around less when the preview is shown and hidden. |
| 562 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -557,5 +557,47 @@ | |
| 557 | rendering a preview wildly resizes the widget. The effect is |
| 558 | especially helpful when working on posts while the bottom footer of |
| 559 | the page is in the viewport, as the footer is a hard boundary against |
| 560 | scrolling. With the extra padding, the editor widget's top edge shifts |
| 561 | around less when the preview is shown and hidden. |
| 562 | |
| 563 | <h2 name="fork">Forked Edits</h2> |
| 564 | |
| 565 | It is possible to "fork" forum messages, in the same way that any |
| 566 | given check-in may cause a fork. This can happen when a message is |
| 567 | edited concurrently from two or more browser tabs or via two or more |
| 568 | fossil instances which subsequently sync with each other. |
| 569 | |
| 570 | When a forum post is forked, the UI currently behaves as it does for |
| 571 | concurrent wiki page edits, showing only the most recent |
| 572 | edit. Currently (2026-06) the UI is incapable of showing the older |
| 573 | forked copies but (A) the data are still part of the SCM history and |
| 574 | (B) there are plans to improve the UI to show such forks. |
| 575 | |
| 576 | For trivia's sake, here's a query which finds posts which have |
| 577 | forks: |
| 578 | |
| 579 | <pre><verbatim> |
| 580 | SELECT bp.rid AS parentRid, bp.uuid parentUuid, count(f.fprev) forkCount |
| 581 | FROM blob b, blob bp, forumpost f |
| 582 | WHERE b.rid=f.fpid |
| 583 | AND f.fprev=bp.rid |
| 584 | GROUP BY f.fprev |
| 585 | HAVING forkCount>1; |
| 586 | </verbatim></pre> |
| 587 | |
| 588 | And here's one which lists forked posts: |
| 589 | |
| 590 | <pre><verbatim> |
| 591 | WITH multiparent(mpid) AS ( |
| 592 | SELECT fprev FROM forumpost f |
| 593 | GROUP BY fprev |
| 594 | HAVING count(fprev)>1 |
| 595 | ) |
| 596 | SELECT datetime(fmtime), forumpost.* |
| 597 | FROM forumpost, multiparent |
| 598 | WHERE fprev=mpid |
| 599 | ORDER BY mpid, fpid, fmtime; |
| 600 | </verbatim></pre> |
| 601 | |
| 602 | The telling part is the <code>fprev</code> column: those with matching |
| 603 | values forked from the post referred to by <code>fprev</code>. |
| 604 |