Fossil SCM
Added "toggle" attributes to the pikchrs in the branching and rebase harm docs, so they act as inline examples of the tech.
Commit
01f6ed9c9a78d80976b50e89166a00b8a2effcb9df525fa3e48b18aeed5b9398
Parent
a9d0c2a68c326c2…
2 files changed
+6
-6
+5
-5
+6
-6
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -2,11 +2,11 @@ | ||
| 2 | 2 | <h2>Background</h2> |
| 3 | 3 | |
| 4 | 4 | In a simple and perfect world, the development of a project would proceed |
| 5 | 5 | linearly, as shown in Figure 1. |
| 6 | 6 | |
| 7 | -<verbatim type="pikchr center"> | |
| 7 | +<verbatim type="pikchr center toggle"> | |
| 8 | 8 | ALL: [circle rad 40% thickness 1.5px "1" |
| 9 | 9 | arrow right 40% |
| 10 | 10 | circle same "2" |
| 11 | 11 | arrow same |
| 12 | 12 | circle same "3" |
| @@ -42,11 +42,11 @@ | ||
| 42 | 42 | |
| 43 | 43 | Alas, reality often interferes with the simple linear development of a |
| 44 | 44 | project. Suppose two programmers make independent modifications to check-in 2. |
| 45 | 45 | After both changes are committed, the check-in graph looks like Figure 2: |
| 46 | 46 | |
| 47 | -<verbatim type="pikchr center"> | |
| 47 | +<verbatim type="pikchr center toggle"> | |
| 48 | 48 | ALL: [circle rad 40% thickness 1.5px "1" |
| 49 | 49 | arrow right 40% |
| 50 | 50 | circle same "2" |
| 51 | 51 | circle same "3" at 2nd circle+(.4,.3) |
| 52 | 52 | arrow from 2nd circle to 3rd circle chop |
| @@ -118,11 +118,11 @@ | ||
| 118 | 118 | check-in 3. Without arguments, that command merges all leaves on the |
| 119 | 119 | current branch. Alice can then verify that the merge is sensible and if |
| 120 | 120 | so, commit the results as check-in 5. This results in a DAG as shown in |
| 121 | 121 | Figure 3. |
| 122 | 122 | |
| 123 | -<verbatim type="pikchr center"> | |
| 123 | +<verbatim type="pikchr center toggle"> | |
| 124 | 124 | ALL: [circle rad 40% thickness 1.5px "1" |
| 125 | 125 | arrow right 40% |
| 126 | 126 | circle same "2" |
| 127 | 127 | circle same "3" at 2nd circle+(.4,.3) |
| 128 | 128 | arrow from 2nd circle to 3rd circle chop |
| @@ -181,11 +181,11 @@ | ||
| 181 | 181 | instead of <i>forking</i>: |
| 182 | 182 | |
| 183 | 183 | Figure 4 shows an example of a project where there are two branches, one |
| 184 | 184 | for development work and another for testing. |
| 185 | 185 | |
| 186 | -<verbatim type="pikchr center"> | |
| 186 | +<verbatim type="pikchr center toggle"> | |
| 187 | 187 | ALL: [circle rad 40% thickness 1.5px fill white "1" |
| 188 | 188 | arrow 40% |
| 189 | 189 | C2: circle same "2" |
| 190 | 190 | arrow same |
| 191 | 191 | circle same "3" |
| @@ -391,11 +391,11 @@ | ||
| 391 | 391 | |
| 392 | 392 | Tags and properties are used in Fossil to help express the intent, and |
| 393 | 393 | thus to distinguish between forks and branches. Figure 5 shows the |
| 394 | 394 | same scenario as Figure 4 but with tags and properties added: |
| 395 | 395 | |
| 396 | -<verbatim type="pikchr center"> | |
| 396 | +<verbatim type="pikchr center toggle"> | |
| 397 | 397 | ALL: [arrowht = 0.07 |
| 398 | 398 | C1: circle rad 40% thickness 1.5px fill white "1" |
| 399 | 399 | arrow 40% |
| 400 | 400 | C2: circle same "2" |
| 401 | 401 | arrow same |
| @@ -491,11 +491,11 @@ | ||
| 491 | 491 | [#dist-clone|Above], we stated that forks carry a risk that development |
| 492 | 492 | effort on a branch can be divided among the forks. It might not be |
| 493 | 493 | immediately obvious why this is so. To see it, consider this swim lane |
| 494 | 494 | diagram: |
| 495 | 495 | |
| 496 | -<verbatim type="pikchr center"> | |
| 496 | +<verbatim type="pikchr center toggle toggle"> | |
| 497 | 497 | $laneh = 0.75 |
| 498 | 498 | |
| 499 | 499 | ALL: [ |
| 500 | 500 | # Draw the lanes |
| 501 | 501 | down |
| 502 | 502 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | <h2>Background</h2> |
| 3 | |
| 4 | In a simple and perfect world, the development of a project would proceed |
| 5 | linearly, as shown in Figure 1. |
| 6 | |
| 7 | <verbatim type="pikchr center"> |
| 8 | ALL: [circle rad 40% thickness 1.5px "1" |
| 9 | arrow right 40% |
| 10 | circle same "2" |
| 11 | arrow same |
| 12 | circle same "3" |
| @@ -42,11 +42,11 @@ | |
| 42 | |
| 43 | Alas, reality often interferes with the simple linear development of a |
| 44 | project. Suppose two programmers make independent modifications to check-in 2. |
| 45 | After both changes are committed, the check-in graph looks like Figure 2: |
| 46 | |
| 47 | <verbatim type="pikchr center"> |
| 48 | ALL: [circle rad 40% thickness 1.5px "1" |
| 49 | arrow right 40% |
| 50 | circle same "2" |
| 51 | circle same "3" at 2nd circle+(.4,.3) |
| 52 | arrow from 2nd circle to 3rd circle chop |
| @@ -118,11 +118,11 @@ | |
| 118 | check-in 3. Without arguments, that command merges all leaves on the |
| 119 | current branch. Alice can then verify that the merge is sensible and if |
| 120 | so, commit the results as check-in 5. This results in a DAG as shown in |
| 121 | Figure 3. |
| 122 | |
| 123 | <verbatim type="pikchr center"> |
| 124 | ALL: [circle rad 40% thickness 1.5px "1" |
| 125 | arrow right 40% |
| 126 | circle same "2" |
| 127 | circle same "3" at 2nd circle+(.4,.3) |
| 128 | arrow from 2nd circle to 3rd circle chop |
| @@ -181,11 +181,11 @@ | |
| 181 | instead of <i>forking</i>: |
| 182 | |
| 183 | Figure 4 shows an example of a project where there are two branches, one |
| 184 | for development work and another for testing. |
| 185 | |
| 186 | <verbatim type="pikchr center"> |
| 187 | ALL: [circle rad 40% thickness 1.5px fill white "1" |
| 188 | arrow 40% |
| 189 | C2: circle same "2" |
| 190 | arrow same |
| 191 | circle same "3" |
| @@ -391,11 +391,11 @@ | |
| 391 | |
| 392 | Tags and properties are used in Fossil to help express the intent, and |
| 393 | thus to distinguish between forks and branches. Figure 5 shows the |
| 394 | same scenario as Figure 4 but with tags and properties added: |
| 395 | |
| 396 | <verbatim type="pikchr center"> |
| 397 | ALL: [arrowht = 0.07 |
| 398 | C1: circle rad 40% thickness 1.5px fill white "1" |
| 399 | arrow 40% |
| 400 | C2: circle same "2" |
| 401 | arrow same |
| @@ -491,11 +491,11 @@ | |
| 491 | [#dist-clone|Above], we stated that forks carry a risk that development |
| 492 | effort on a branch can be divided among the forks. It might not be |
| 493 | immediately obvious why this is so. To see it, consider this swim lane |
| 494 | diagram: |
| 495 | |
| 496 | <verbatim type="pikchr center"> |
| 497 | $laneh = 0.75 |
| 498 | |
| 499 | ALL: [ |
| 500 | # Draw the lanes |
| 501 | down |
| 502 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -2,11 +2,11 @@ | |
| 2 | <h2>Background</h2> |
| 3 | |
| 4 | In a simple and perfect world, the development of a project would proceed |
| 5 | linearly, as shown in Figure 1. |
| 6 | |
| 7 | <verbatim type="pikchr center toggle"> |
| 8 | ALL: [circle rad 40% thickness 1.5px "1" |
| 9 | arrow right 40% |
| 10 | circle same "2" |
| 11 | arrow same |
| 12 | circle same "3" |
| @@ -42,11 +42,11 @@ | |
| 42 | |
| 43 | Alas, reality often interferes with the simple linear development of a |
| 44 | project. Suppose two programmers make independent modifications to check-in 2. |
| 45 | After both changes are committed, the check-in graph looks like Figure 2: |
| 46 | |
| 47 | <verbatim type="pikchr center toggle"> |
| 48 | ALL: [circle rad 40% thickness 1.5px "1" |
| 49 | arrow right 40% |
| 50 | circle same "2" |
| 51 | circle same "3" at 2nd circle+(.4,.3) |
| 52 | arrow from 2nd circle to 3rd circle chop |
| @@ -118,11 +118,11 @@ | |
| 118 | check-in 3. Without arguments, that command merges all leaves on the |
| 119 | current branch. Alice can then verify that the merge is sensible and if |
| 120 | so, commit the results as check-in 5. This results in a DAG as shown in |
| 121 | Figure 3. |
| 122 | |
| 123 | <verbatim type="pikchr center toggle"> |
| 124 | ALL: [circle rad 40% thickness 1.5px "1" |
| 125 | arrow right 40% |
| 126 | circle same "2" |
| 127 | circle same "3" at 2nd circle+(.4,.3) |
| 128 | arrow from 2nd circle to 3rd circle chop |
| @@ -181,11 +181,11 @@ | |
| 181 | instead of <i>forking</i>: |
| 182 | |
| 183 | Figure 4 shows an example of a project where there are two branches, one |
| 184 | for development work and another for testing. |
| 185 | |
| 186 | <verbatim type="pikchr center toggle"> |
| 187 | ALL: [circle rad 40% thickness 1.5px fill white "1" |
| 188 | arrow 40% |
| 189 | C2: circle same "2" |
| 190 | arrow same |
| 191 | circle same "3" |
| @@ -391,11 +391,11 @@ | |
| 391 | |
| 392 | Tags and properties are used in Fossil to help express the intent, and |
| 393 | thus to distinguish between forks and branches. Figure 5 shows the |
| 394 | same scenario as Figure 4 but with tags and properties added: |
| 395 | |
| 396 | <verbatim type="pikchr center toggle"> |
| 397 | ALL: [arrowht = 0.07 |
| 398 | C1: circle rad 40% thickness 1.5px fill white "1" |
| 399 | arrow 40% |
| 400 | C2: circle same "2" |
| 401 | arrow same |
| @@ -491,11 +491,11 @@ | |
| 491 | [#dist-clone|Above], we stated that forks carry a risk that development |
| 492 | effort on a branch can be divided among the forks. It might not be |
| 493 | immediately obvious why this is so. To see it, consider this swim lane |
| 494 | diagram: |
| 495 | |
| 496 | <verbatim type="pikchr center toggle toggle"> |
| 497 | $laneh = 0.75 |
| 498 | |
| 499 | ALL: [ |
| 500 | # Draw the lanes |
| 501 | down |
| 502 |
+5
-5
| --- www/rebaseharm.md | ||
| +++ www/rebaseharm.md | ||
| @@ -30,11 +30,11 @@ | ||
| 30 | 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | 31 | To help illustrate this fact, |
| 32 | 32 | consider the first rebase example from the |
| 33 | 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | 34 | |
| 35 | -~~~ pikchr | |
| 35 | +~~~ pikchr toggle | |
| 36 | 36 | scale = 0.8 |
| 37 | 37 | circle "C0" fit |
| 38 | 38 | arrow right 50% |
| 39 | 39 | circle same "C1" |
| 40 | 40 | arrow same |
| @@ -48,11 +48,11 @@ | ||
| 48 | 48 | arrow from C4 to C5 chop |
| 49 | 49 | ~~~ |
| 50 | 50 | |
| 51 | 51 | And the rebase looks like this: |
| 52 | 52 | |
| 53 | -~~~ pikchr | |
| 53 | +~~~ pikchr toggle | |
| 54 | 54 | scale = 0.8 |
| 55 | 55 | circle "C0" fit |
| 56 | 56 | arrow right 50% |
| 57 | 57 | circle same "C1" |
| 58 | 58 | arrow same |
| @@ -95,11 +95,11 @@ | ||
| 95 | 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | 96 | allows one to see just the changes in the feature branch without |
| 97 | 97 | the concurrent changes in the main line of development. |
| 98 | 98 | Consider a hypothetical case: |
| 99 | 99 | |
| 100 | -~~~ pikchr | |
| 100 | +~~~ pikchr toggle | |
| 101 | 101 | scale = 0.8 |
| 102 | 102 | circle "C0" fit fill white |
| 103 | 103 | arrow right 50% |
| 104 | 104 | circle same "C1" |
| 105 | 105 | arrow same |
| @@ -123,11 +123,11 @@ | ||
| 123 | 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | 125 | of main in order to remove main-line development differences from |
| 126 | 126 | the feature branch's history: |
| 127 | 127 | |
| 128 | -~~~ pikchr | |
| 128 | +~~~ pikchr toggle | |
| 129 | 129 | scale = 0.8 |
| 130 | 130 | circle "C0" fit fill white |
| 131 | 131 | arrow right 50% |
| 132 | 132 | circle same "C1" |
| 133 | 133 | arrow same |
| @@ -157,11 +157,11 @@ | ||
| 157 | 157 | [separately](#collapsing). |
| 158 | 158 | |
| 159 | 159 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 160 | 160 | history is the following merge: |
| 161 | 161 | |
| 162 | -~~~ pikchr | |
| 162 | +~~~ pikchr toggle | |
| 163 | 163 | scale = 0.8 |
| 164 | 164 | circle "C0" fit fill white |
| 165 | 165 | arrow right 50% |
| 166 | 166 | circle same "C1" |
| 167 | 167 | arrow same |
| 168 | 168 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | To help illustrate this fact, |
| 32 | consider the first rebase example from the |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 | ~~~ pikchr |
| 36 | scale = 0.8 |
| 37 | circle "C0" fit |
| 38 | arrow right 50% |
| 39 | circle same "C1" |
| 40 | arrow same |
| @@ -48,11 +48,11 @@ | |
| 48 | arrow from C4 to C5 chop |
| 49 | ~~~ |
| 50 | |
| 51 | And the rebase looks like this: |
| 52 | |
| 53 | ~~~ pikchr |
| 54 | scale = 0.8 |
| 55 | circle "C0" fit |
| 56 | arrow right 50% |
| 57 | circle same "C1" |
| 58 | arrow same |
| @@ -95,11 +95,11 @@ | |
| 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | allows one to see just the changes in the feature branch without |
| 97 | the concurrent changes in the main line of development. |
| 98 | Consider a hypothetical case: |
| 99 | |
| 100 | ~~~ pikchr |
| 101 | scale = 0.8 |
| 102 | circle "C0" fit fill white |
| 103 | arrow right 50% |
| 104 | circle same "C1" |
| 105 | arrow same |
| @@ -123,11 +123,11 @@ | |
| 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | of main in order to remove main-line development differences from |
| 126 | the feature branch's history: |
| 127 | |
| 128 | ~~~ pikchr |
| 129 | scale = 0.8 |
| 130 | circle "C0" fit fill white |
| 131 | arrow right 50% |
| 132 | circle same "C1" |
| 133 | arrow same |
| @@ -157,11 +157,11 @@ | |
| 157 | [separately](#collapsing). |
| 158 | |
| 159 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 160 | history is the following merge: |
| 161 | |
| 162 | ~~~ pikchr |
| 163 | scale = 0.8 |
| 164 | circle "C0" fit fill white |
| 165 | arrow right 50% |
| 166 | circle same "C1" |
| 167 | arrow same |
| 168 |
| --- www/rebaseharm.md | |
| +++ www/rebaseharm.md | |
| @@ -30,11 +30,11 @@ | |
| 30 | that deliberately forgets one of the parents of each merge step. |
| 31 | To help illustrate this fact, |
| 32 | consider the first rebase example from the |
| 33 | [Git documentation][gitrebase]. The merge looks like this: |
| 34 | |
| 35 | ~~~ pikchr toggle |
| 36 | scale = 0.8 |
| 37 | circle "C0" fit |
| 38 | arrow right 50% |
| 39 | circle same "C1" |
| 40 | arrow same |
| @@ -48,11 +48,11 @@ | |
| 48 | arrow from C4 to C5 chop |
| 49 | ~~~ |
| 50 | |
| 51 | And the rebase looks like this: |
| 52 | |
| 53 | ~~~ pikchr toggle |
| 54 | scale = 0.8 |
| 55 | circle "C0" fit |
| 56 | arrow right 50% |
| 57 | circle same "C1" |
| 58 | arrow same |
| @@ -95,11 +95,11 @@ | |
| 95 | Another argument, often cited, is that rebasing a feature branch |
| 96 | allows one to see just the changes in the feature branch without |
| 97 | the concurrent changes in the main line of development. |
| 98 | Consider a hypothetical case: |
| 99 | |
| 100 | ~~~ pikchr toggle |
| 101 | scale = 0.8 |
| 102 | circle "C0" fit fill white |
| 103 | arrow right 50% |
| 104 | circle same "C1" |
| 105 | arrow same |
| @@ -123,11 +123,11 @@ | |
| 123 | run concurrently with the main line in check-ins C4 and C6. Advocates |
| 124 | for rebase say that you should rebase the feature branch to the tip |
| 125 | of main in order to remove main-line development differences from |
| 126 | the feature branch's history: |
| 127 | |
| 128 | ~~~ pikchr toggle |
| 129 | scale = 0.8 |
| 130 | circle "C0" fit fill white |
| 131 | arrow right 50% |
| 132 | circle same "C1" |
| 133 | arrow same |
| @@ -157,11 +157,11 @@ | |
| 157 | [separately](#collapsing). |
| 158 | |
| 159 | Because Fossil purposefully lacks rebase, the closest you can get to this same check-in |
| 160 | history is the following merge: |
| 161 | |
| 162 | ~~~ pikchr toggle |
| 163 | scale = 0.8 |
| 164 | circle "C0" fit fill white |
| 165 | arrow right 50% |
| 166 | circle same "C1" |
| 167 | arrow same |
| 168 |