Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Changes In Branch extract-pikchr Excluding Merge-Ins
This is equivalent to a diff from 1ddb4008 to a9dcda5d
|
2020-10-12
| ||
| 13:39 | New document: pikchr.md ... (check-in: a92365d7 user: drh tags: trunk) | |
|
2020-10-11
| ||
| 07:03 |
Attempt to use the feature added in [e32214a409] to extract the
duplicate Pikchr code for diagram #4 in the rebase doc as a separate
file, so we can refer to it twice via a Markdown image link instead.
Doesn't work, but my next steps require a checkin I can reference.
EDIT: Per forum feedback (https://fossil-scm.org/forum/forumpost/5c177b55b6) I'm abandoning this. ... (Closed-Leaf check-in: a9dcda5d user: wyoung tags: extract-pikchr) | |
| 06:51 | Greatly expanded the simple definition of "blockchain" in the eponymous doc to include more details of common blockchain implementations to draw clearer parallels. This causes our conclusion to flip around from the prior version of this doc, but it's worth keeping the doc because it serves to compare and contrast Fossil to other systems. ... (check-in: 1ddb4008 user: wyoung tags: trunk) | |
| 01:19 | Understand files ending in ".pikchr" to be Pikchr source text and render them appropriately. ... (check-in: e32214a4 user: drh tags: trunk) | |
|
2020-10-08
| ||
| 08:48 | Drew better analogies between Bitcoin's answer to the 51% attack and to GitHub in the new Anonymity section of the blockchain doc to show that Fossil doesn't even try to provide the sorts of behavior that allow fully anonymous contribution to a blockchain. ... (Closed-Leaf check-in: 87b1385d user: wyoung tags: fossil-as-blockchain) | |
Added www/rebase04.pikchr.
> > > > > > > > > > > > > > > > > > > > > > > > > > | 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 | # Commit diagram referenced twice from rebaseharm.md, so we keep it # external, to avoid duplicate inline code. scale = 0.8 circle "C0" fit fill white arrow right 50% circle same "C1" arrow same circle same "C2" arrow same circle same "C4" arrow same circle same "C6" circle same "C3" at last arrow.width + C0.rad*2 heading 30 from C2 arrow right 50% circle same "C5" arrow from C2 to C3 chop C3P: circle same "C3'" at first arrow.width + C0.rad*2 heading 30 from C6 arrow right 50% from C3P.e C5P: circle same "C5'" arrow from C6 to C3P chop box ht C3.y-C2.y wid C5P.e.x-C0.w.x+1.5*C1.rad with .w at 0.5*(first arrow.wid) west of C0.w \ behind C0 fill 0xc6e2ff color 0xaac5df box ht previous.ht wid previous.e.x - C2.w.x with .se at previous.ne \ behind C0 fill 0x9accfc color 0xaac5df |
Changes to www/rebaseharm.md.
| ︙ | ︙ | |||
121 122 123 124 125 126 127 | In the above, a feature branch consisting of check-ins C3 and C5 is run concurrently with the main line in check-ins C4 and C6. Advocates for rebase say that you should rebase the feature branch to the tip of main in order to remove main-line development differences from the feature branch's history: | < < | < < < < < < < < < < < < < < < < < < < < < < > | 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 | In the above, a feature branch consisting of check-ins C3 and C5 is run concurrently with the main line in check-ins C4 and C6. Advocates for rebase say that you should rebase the feature branch to the tip of main in order to remove main-line development differences from the feature branch's history: ![rebase diagram][4] [4]: ./rebase04.pikchr You could choose to collapse C3\' and C5\' into a single check-in as part of this rebase, but that's a side issue we'll deal with [separately](#collapsing). Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| ︙ | ︙ | |||
253 254 255 256 257 258 259 | branch to the parent repo? Will the many eyeballs even see those errors when they’re intermingled with code implementing some compelling new feature? ## <a name="timestamps"></a>4.0 Rebase causes timestamp confusion Consider the earlier example of rebasing a feature branch: | < < < < < < < < < < < < < < < < < < < < | < < < < < | 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 | branch to the parent repo? Will the many eyeballs even see those errors when they’re intermingled with code implementing some compelling new feature? ## <a name="timestamps"></a>4.0 Rebase causes timestamp confusion Consider the earlier example of rebasing a feature branch: ![rebase diagram from section 2.2 again][4] What timestamps go on the C3\' and C5\' check-ins? If you choose the same timestamps as the original C3 and C5, then you have the odd situation C3' is older than its parent C6. We call that a "timewarp" in Fossil. Timewarps can also happen due to misconfigured system clocks, so they are not unique to rebase, but they are very confusing and so best avoided. The other option is to provide new |
| ︙ | ︙ |