Fossil SCM
Cleaned up a few inconsistencies in the Pikchrs in the branching doc in an attempt to fix the smaller-and-smaller diagram size problem currently occuring in this doc.
Commit
239fb5b186aff29786510e6eebf6060a5fb6985c29459a70be5832924ce3bdfb
Parent
6a3d6fa63e05e64…
1 file changed
+6
-6
+6
-6
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -3,11 +3,11 @@ | ||
| 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 | 7 | <verbatim type="pikchr center toggle"> |
| 8 | -ALL: [circle rad 40% thickness 1.5px "1" | |
| 8 | +ALL: [circle rad 0.1in thickness 1.5px "1" | |
| 9 | 9 | arrow right 40% |
| 10 | 10 | circle same "2" |
| 11 | 11 | arrow same |
| 12 | 12 | circle same "3" |
| 13 | 13 | arrow same |
| @@ -43,11 +43,11 @@ | ||
| 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 | 47 | <verbatim type="pikchr center toggle"> |
| 48 | -ALL: [circle rad 40% thickness 1.5px "1" | |
| 48 | +ALL: [circle rad 0.1in 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 |
| 53 | 53 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -119,11 +119,11 @@ | ||
| 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 | 123 | <verbatim type="pikchr center toggle"> |
| 124 | -ALL: [circle rad 40% thickness 1.5px "1" | |
| 124 | +ALL: [circle rad 0.1in 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 |
| 129 | 129 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -182,11 +182,11 @@ | ||
| 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 | 186 | <verbatim type="pikchr center toggle"> |
| 187 | -ALL: [circle rad 40% thickness 1.5px fill white "1" | |
| 187 | +ALL: [circle rad 0.1in 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" |
| 192 | 192 | arrow same |
| @@ -393,11 +393,11 @@ | ||
| 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 | 396 | <verbatim type="pikchr center toggle"> |
| 397 | 397 | ALL: [arrowht = 0.07 |
| 398 | -C1: circle rad 40% thickness 1.5px fill white "1" | |
| 398 | +C1: circle rad 0.1in thickness 1.5px fill white "1" | |
| 399 | 399 | arrow 40% |
| 400 | 400 | C2: circle same "2" |
| 401 | 401 | arrow same |
| 402 | 402 | circle same "3" |
| 403 | 403 | arrow same |
| @@ -424,11 +424,11 @@ | ||
| 424 | 424 | box same "branch=test" "sym-test" "bgcolor=blue" "cancel=sym-trunk" fit \ |
| 425 | 425 | with .n at C4-(0,0.3) |
| 426 | 426 | line color gray from last box.n to C4 chop |
| 427 | 427 | box same "sym-release-1.0" "closed" fit with .n at C9-(0,0.3) |
| 428 | 428 | line color gray from last box.n to C9 chop] |
| 429 | -box invis "Figure 5" bold fit with .n at 0.2cm below ALL.s | |
| 429 | +box invis "Figure 5" big fit with .n at 0.2cm below ALL.s | |
| 430 | 430 | </verbatim> |
| 431 | 431 | |
| 432 | 432 | A <i>tag</i> is a name that is attached to a check-in. A |
| 433 | 433 | <i>property</i> is a name/value pair. Internally, Fossil implements |
| 434 | 434 | tags as properties with a NULL value. So, tags and properties really |
| 435 | 435 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -3,11 +3,11 @@ | |
| 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" |
| 13 | arrow same |
| @@ -43,11 +43,11 @@ | |
| 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 |
| 53 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -119,11 +119,11 @@ | |
| 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 |
| 129 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -182,11 +182,11 @@ | |
| 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" |
| 192 | arrow same |
| @@ -393,11 +393,11 @@ | |
| 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 |
| 402 | circle same "3" |
| 403 | arrow same |
| @@ -424,11 +424,11 @@ | |
| 424 | box same "branch=test" "sym-test" "bgcolor=blue" "cancel=sym-trunk" fit \ |
| 425 | with .n at C4-(0,0.3) |
| 426 | line color gray from last box.n to C4 chop |
| 427 | box same "sym-release-1.0" "closed" fit with .n at C9-(0,0.3) |
| 428 | line color gray from last box.n to C9 chop] |
| 429 | box invis "Figure 5" bold fit with .n at 0.2cm below ALL.s |
| 430 | </verbatim> |
| 431 | |
| 432 | A <i>tag</i> is a name that is attached to a check-in. A |
| 433 | <i>property</i> is a name/value pair. Internally, Fossil implements |
| 434 | tags as properties with a NULL value. So, tags and properties really |
| 435 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -3,11 +3,11 @@ | |
| 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 0.1in thickness 1.5px "1" |
| 9 | arrow right 40% |
| 10 | circle same "2" |
| 11 | arrow same |
| 12 | circle same "3" |
| 13 | arrow same |
| @@ -43,11 +43,11 @@ | |
| 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 0.1in 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 |
| 53 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -119,11 +119,11 @@ | |
| 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 0.1in 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 |
| 129 | circle same "4" at 2nd circle+(.4,-.3) |
| @@ -182,11 +182,11 @@ | |
| 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 0.1in thickness 1.5px fill white "1" |
| 188 | arrow 40% |
| 189 | C2: circle same "2" |
| 190 | arrow same |
| 191 | circle same "3" |
| 192 | arrow same |
| @@ -393,11 +393,11 @@ | |
| 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 0.1in thickness 1.5px fill white "1" |
| 399 | arrow 40% |
| 400 | C2: circle same "2" |
| 401 | arrow same |
| 402 | circle same "3" |
| 403 | arrow same |
| @@ -424,11 +424,11 @@ | |
| 424 | box same "branch=test" "sym-test" "bgcolor=blue" "cancel=sym-trunk" fit \ |
| 425 | with .n at C4-(0,0.3) |
| 426 | line color gray from last box.n to C4 chop |
| 427 | box same "sym-release-1.0" "closed" fit with .n at C9-(0,0.3) |
| 428 | line color gray from last box.n to C9 chop] |
| 429 | box invis "Figure 5" big fit with .n at 0.2cm below ALL.s |
| 430 | </verbatim> |
| 431 | |
| 432 | A <i>tag</i> is a name that is attached to a check-in. A |
| 433 | <i>property</i> is a name/value pair. Internally, Fossil implements |
| 434 | tags as properties with a NULL value. So, tags and properties really |
| 435 |