Fossil SCM
In the branching.wiki document, make the figure numbers part of the Pikchr, thus avoiding the need for tables, and allowing the figures to scale on mobile devices.
Commit
299e06435d51e830d6dbd34603e6f2727ae4eef3c39cce81b4e6a47a7880786f
Parent
75d4517515e7538…
1 file changed
+22
-40
+22
-40
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -2,23 +2,20 @@ | ||
| 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 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 8 | -<tr><td align="center"> | |
| 9 | 7 | <verbatim type="pikchr center"> |
| 10 | -circle rad 40% thickness 1.5px "1" | |
| 8 | +ALL: [circle rad 40% thickness 1.5px "1" | |
| 11 | 9 | arrow right 40% |
| 12 | 10 | circle same "2" |
| 13 | 11 | arrow same |
| 14 | 12 | circle same "3" |
| 15 | 13 | arrow same |
| 16 | -circle same "4" | |
| 14 | +circle same "4"] | |
| 15 | +box invis "Figure 1" big fit with .n at .3cm below ALL.s | |
| 17 | 16 | </verbatim> |
| 18 | -Figure 1 | |
| 19 | -</td></tr></table> | |
| 20 | 17 | |
| 21 | 18 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 22 | 19 | are given small consecutive numbers. In a real system, of course, the |
| 23 | 20 | check-in numbers would be long hexadecimal hashes since it is not possible |
| 24 | 21 | to allocate collision-free sequential numbers in a distributed system. |
| @@ -45,23 +42,20 @@ | ||
| 45 | 42 | |
| 46 | 43 | Alas, reality often interferes with the simple linear development of a |
| 47 | 44 | project. Suppose two programmers make independent modifications to check-in 2. |
| 48 | 45 | After both changes are committed, the check-in graph looks like Figure 2: |
| 49 | 46 | |
| 50 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 51 | -<tr><td align="center"> | |
| 52 | 47 | <verbatim type="pikchr center"> |
| 53 | -circle rad 40% thickness 1.5px "1" | |
| 48 | +ALL: [circle rad 40% thickness 1.5px "1" | |
| 54 | 49 | arrow right 40% |
| 55 | 50 | circle same "2" |
| 56 | 51 | circle same "3" at 2nd circle+(.4,.3) |
| 57 | 52 | arrow from 2nd circle to 3rd circle chop |
| 58 | 53 | circle same "4" at 2nd circle+(.4,-.3) |
| 59 | -arrow from 2nd circle to 4th circle chop | |
| 54 | +arrow from 2nd circle to 4th circle chop] | |
| 55 | +box invis "Figure 2" big fit with .n at .3cm below ALL.s | |
| 60 | 56 | </verbatim> |
| 61 | -Figure 2 | |
| 62 | -</td></tr></table> | |
| 63 | 57 | |
| 64 | 58 | The graph in Figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has |
| 65 | 59 | two children, check-ins 3 and 4. We call this state a <i>fork</i>. |
| 66 | 60 | |
| 67 | 61 | Fossil tries to prevent forks, primarily through its |
| @@ -124,26 +118,23 @@ | ||
| 124 | 118 | check-in 3. Without arguments, that command merges all leaves on the |
| 125 | 119 | current branch. Alice can then verify that the merge is sensible and if |
| 126 | 120 | so, commit the results as check-in 5. This results in a DAG as shown in |
| 127 | 121 | Figure 3. |
| 128 | 122 | |
| 129 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 130 | -<tr><td align="cent"> | |
| 131 | -<verbatim type="pikchr"> | |
| 132 | -circle rad 40% thickness 1.5px "1" | |
| 123 | +<verbatim type="pikchr center"> | |
| 124 | +ALL: [circle rad 40% thickness 1.5px "1" | |
| 133 | 125 | arrow right 40% |
| 134 | 126 | circle same "2" |
| 135 | 127 | circle same "3" at 2nd circle+(.4,.3) |
| 136 | 128 | arrow from 2nd circle to 3rd circle chop |
| 137 | 129 | circle same "4" at 2nd circle+(.4,-.3) |
| 138 | 130 | arrow from 2nd circle to 4th circle chop |
| 139 | 131 | circle same "5" at 3rd circle+(.4,-.3) |
| 140 | 132 | arrow from 3rd circle to 5th circle chop |
| 141 | -arrow dashed .03 from 4th circle to 5th circle chop | |
| 133 | +arrow dashed .03 from 4th circle to 5th circle chop] | |
| 134 | +box invis "Figure 3" big fit with .n at .2cm below ALL.s | |
| 142 | 135 | </verbatim> |
| 143 | -Figure 3 | |
| 144 | -</td></tr></table> | |
| 145 | 136 | |
| 146 | 137 | Check-in 5 is a child of check-in 3 because it was created by editing |
| 147 | 138 | check-in 3, but since check-in 5 also inherits the changes from check-in 4 by |
| 148 | 139 | virtue of the merge, we say that check-in 5 is a <i>merge child</i> |
| 149 | 140 | of check-in 4 and that it is a <i>direct child</i> of check-in 3. |
| @@ -190,14 +181,12 @@ | ||
| 190 | 181 | instead of <i>forking</i>: |
| 191 | 182 | |
| 192 | 183 | Figure 4 shows an example of a project where there are two branches, one |
| 193 | 184 | for development work and another for testing. |
| 194 | 185 | |
| 195 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 196 | -<tr><td align="center"> | |
| 197 | -<verbatim type="pikchr"> | |
| 198 | -circle rad 40% thickness 1.5px fill white "1" | |
| 186 | +<verbatim type="pikchr center"> | |
| 187 | +ALL: [circle rad 40% thickness 1.5px fill white "1" | |
| 199 | 188 | arrow 40% |
| 200 | 189 | C2: circle same "2" |
| 201 | 190 | arrow same |
| 202 | 191 | circle same "3" |
| 203 | 192 | arrow same |
| @@ -216,15 +205,13 @@ | ||
| 216 | 205 | arrow from C6 to C9 chop |
| 217 | 206 | arrow dashed 0.03 from C6 to C7 chop |
| 218 | 207 | arrow same from C9 to C10 |
| 219 | 208 | layer = 0 |
| 220 | 209 | box fill 0x9bcdfc color 0x9bcdfc wid (C10.e.x - C2.w.x) ht C6.height*1.5 at C6.c |
| 221 | -text " test" above ljust at last box.sw | |
| 210 | +box invis "test" fit with .sw at last box.sw] | |
| 211 | +box invis "Figure 4" big with .n at 0 below ALL.s | |
| 222 | 212 | </verbatim> |
| 223 | -<p> | |
| 224 | -Figure 4 | |
| 225 | -</td></tr></table> | |
| 226 | 213 | |
| 227 | 214 | Figure 4 diagrams the following scenario: the project starts and |
| 228 | 215 | progresses to a point where (at check-in 2) |
| 229 | 216 | it is ready to enter testing for its first release. |
| 230 | 217 | In a real project, of course, there might be hundreds or thousands of |
| @@ -404,14 +391,12 @@ | ||
| 404 | 391 | |
| 405 | 392 | Tags and properties are used in Fossil to help express the intent, and |
| 406 | 393 | thus to distinguish between forks and branches. Figure 5 shows the |
| 407 | 394 | same scenario as Figure 4 but with tags and properties added: |
| 408 | 395 | |
| 409 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 410 | -<tr><td align="center"> | |
| 411 | -<verbatim type="pikchr"> | |
| 412 | -arrowht = 0.07 | |
| 396 | +<verbatim type="pikchr center"> | |
| 397 | +ALL: [arrowht = 0.07 | |
| 413 | 398 | C1: circle rad 40% thickness 1.5px fill white "1" |
| 414 | 399 | arrow 40% |
| 415 | 400 | C2: circle same "2" |
| 416 | 401 | arrow same |
| 417 | 402 | circle same "3" |
| @@ -438,14 +423,13 @@ | ||
| 438 | 423 | line color gray from last box.ne to C1 chop |
| 439 | 424 | box same "branch=test" "sym-test" "bgcolor=blue" "cancel=sym-trunk" fit \ |
| 440 | 425 | with .n at C4-(0,0.3) |
| 441 | 426 | line color gray from last box.n to C4 chop |
| 442 | 427 | box same "sym-release-1.0" "closed" fit with .n at C9-(0,0.3) |
| 443 | -line color gray from last box.n to C9 chop | |
| 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 | |
| 444 | 430 | </verbatim> |
| 445 | -<p>Figure 5</p> | |
| 446 | -</td></tr></table> | |
| 447 | 431 | |
| 448 | 432 | A <i>tag</i> is a name that is attached to a check-in. A |
| 449 | 433 | <i>property</i> is a name/value pair. Internally, Fossil implements |
| 450 | 434 | tags as properties with a NULL value. So, tags and properties really |
| 451 | 435 | are much the same thing, and henceforth we will use the word "tag" |
| @@ -507,15 +491,14 @@ | ||
| 507 | 491 | [#dist-clone|Above], we stated that forks carry a risk that development |
| 508 | 492 | effort on a branch can be divided among the forks. It might not be |
| 509 | 493 | immediately obvious why this is so. To see it, consider this swim lane |
| 510 | 494 | diagram: |
| 511 | 495 | |
| 512 | -<table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> | |
| 513 | -<tr><td align="center"> | |
| 514 | -<verbatim type="pikchr"> | |
| 496 | +<verbatim type="pikchr center"> | |
| 515 | 497 | $laneh = 0.75 |
| 516 | 498 | |
| 499 | +ALL: [ | |
| 517 | 500 | # Draw the lanes |
| 518 | 501 | down |
| 519 | 502 | box width 3.5in height $laneh fill 0xacc9e3 |
| 520 | 503 | box same fill 0xc5d8ef |
| 521 | 504 | box same as first box |
| @@ -573,14 +556,13 @@ | ||
| 573 | 556 | ellipse same "future" |
| 574 | 557 | D3: circle same as B3 at B3-(0,2*$laneh) "3" |
| 575 | 558 | arrow 50% |
| 576 | 559 | circle same "4" |
| 577 | 560 | arrow from D1 to D3 chop |
| 561 | +] | |
| 562 | +box invis "Figure 6" big fit with .n at 0.2cm below ALL.s | |
| 578 | 563 | </verbatim> |
| 579 | -<br> | |
| 580 | -Figure 6 | |
| 581 | -</td></tr></table> | |
| 582 | 564 | |
| 583 | 565 | This is a happy, cooperating team. That is an important restriction on |
| 584 | 566 | our example, because you must understand that this sort of problem can |
| 585 | 567 | arise without any malice, selfishness, or willful ignorance in sight. |
| 586 | 568 | All users on this diagram start out with the same view of the |
| 587 | 569 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -2,23 +2,20 @@ | |
| 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 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 8 | <tr><td align="center"> |
| 9 | <verbatim type="pikchr center"> |
| 10 | circle rad 40% thickness 1.5px "1" |
| 11 | arrow right 40% |
| 12 | circle same "2" |
| 13 | arrow same |
| 14 | circle same "3" |
| 15 | arrow same |
| 16 | circle same "4" |
| 17 | </verbatim> |
| 18 | Figure 1 |
| 19 | </td></tr></table> |
| 20 | |
| 21 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 22 | are given small consecutive numbers. In a real system, of course, the |
| 23 | check-in numbers would be long hexadecimal hashes since it is not possible |
| 24 | to allocate collision-free sequential numbers in a distributed system. |
| @@ -45,23 +42,20 @@ | |
| 45 | |
| 46 | Alas, reality often interferes with the simple linear development of a |
| 47 | project. Suppose two programmers make independent modifications to check-in 2. |
| 48 | After both changes are committed, the check-in graph looks like Figure 2: |
| 49 | |
| 50 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 51 | <tr><td align="center"> |
| 52 | <verbatim type="pikchr center"> |
| 53 | circle rad 40% thickness 1.5px "1" |
| 54 | arrow right 40% |
| 55 | circle same "2" |
| 56 | circle same "3" at 2nd circle+(.4,.3) |
| 57 | arrow from 2nd circle to 3rd circle chop |
| 58 | circle same "4" at 2nd circle+(.4,-.3) |
| 59 | arrow from 2nd circle to 4th circle chop |
| 60 | </verbatim> |
| 61 | Figure 2 |
| 62 | </td></tr></table> |
| 63 | |
| 64 | The graph in Figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has |
| 65 | two children, check-ins 3 and 4. We call this state a <i>fork</i>. |
| 66 | |
| 67 | Fossil tries to prevent forks, primarily through its |
| @@ -124,26 +118,23 @@ | |
| 124 | check-in 3. Without arguments, that command merges all leaves on the |
| 125 | current branch. Alice can then verify that the merge is sensible and if |
| 126 | so, commit the results as check-in 5. This results in a DAG as shown in |
| 127 | Figure 3. |
| 128 | |
| 129 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 130 | <tr><td align="cent"> |
| 131 | <verbatim type="pikchr"> |
| 132 | circle rad 40% thickness 1.5px "1" |
| 133 | arrow right 40% |
| 134 | circle same "2" |
| 135 | circle same "3" at 2nd circle+(.4,.3) |
| 136 | arrow from 2nd circle to 3rd circle chop |
| 137 | circle same "4" at 2nd circle+(.4,-.3) |
| 138 | arrow from 2nd circle to 4th circle chop |
| 139 | circle same "5" at 3rd circle+(.4,-.3) |
| 140 | arrow from 3rd circle to 5th circle chop |
| 141 | arrow dashed .03 from 4th circle to 5th circle chop |
| 142 | </verbatim> |
| 143 | Figure 3 |
| 144 | </td></tr></table> |
| 145 | |
| 146 | Check-in 5 is a child of check-in 3 because it was created by editing |
| 147 | check-in 3, but since check-in 5 also inherits the changes from check-in 4 by |
| 148 | virtue of the merge, we say that check-in 5 is a <i>merge child</i> |
| 149 | of check-in 4 and that it is a <i>direct child</i> of check-in 3. |
| @@ -190,14 +181,12 @@ | |
| 190 | instead of <i>forking</i>: |
| 191 | |
| 192 | Figure 4 shows an example of a project where there are two branches, one |
| 193 | for development work and another for testing. |
| 194 | |
| 195 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 196 | <tr><td align="center"> |
| 197 | <verbatim type="pikchr"> |
| 198 | circle rad 40% thickness 1.5px fill white "1" |
| 199 | arrow 40% |
| 200 | C2: circle same "2" |
| 201 | arrow same |
| 202 | circle same "3" |
| 203 | arrow same |
| @@ -216,15 +205,13 @@ | |
| 216 | arrow from C6 to C9 chop |
| 217 | arrow dashed 0.03 from C6 to C7 chop |
| 218 | arrow same from C9 to C10 |
| 219 | layer = 0 |
| 220 | box fill 0x9bcdfc color 0x9bcdfc wid (C10.e.x - C2.w.x) ht C6.height*1.5 at C6.c |
| 221 | text " test" above ljust at last box.sw |
| 222 | </verbatim> |
| 223 | <p> |
| 224 | Figure 4 |
| 225 | </td></tr></table> |
| 226 | |
| 227 | Figure 4 diagrams the following scenario: the project starts and |
| 228 | progresses to a point where (at check-in 2) |
| 229 | it is ready to enter testing for its first release. |
| 230 | In a real project, of course, there might be hundreds or thousands of |
| @@ -404,14 +391,12 @@ | |
| 404 | |
| 405 | Tags and properties are used in Fossil to help express the intent, and |
| 406 | thus to distinguish between forks and branches. Figure 5 shows the |
| 407 | same scenario as Figure 4 but with tags and properties added: |
| 408 | |
| 409 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 410 | <tr><td align="center"> |
| 411 | <verbatim type="pikchr"> |
| 412 | arrowht = 0.07 |
| 413 | C1: circle rad 40% thickness 1.5px fill white "1" |
| 414 | arrow 40% |
| 415 | C2: circle same "2" |
| 416 | arrow same |
| 417 | circle same "3" |
| @@ -438,14 +423,13 @@ | |
| 438 | line color gray from last box.ne to C1 chop |
| 439 | box same "branch=test" "sym-test" "bgcolor=blue" "cancel=sym-trunk" fit \ |
| 440 | with .n at C4-(0,0.3) |
| 441 | line color gray from last box.n to C4 chop |
| 442 | box same "sym-release-1.0" "closed" fit with .n at C9-(0,0.3) |
| 443 | line color gray from last box.n to C9 chop |
| 444 | </verbatim> |
| 445 | <p>Figure 5</p> |
| 446 | </td></tr></table> |
| 447 | |
| 448 | A <i>tag</i> is a name that is attached to a check-in. A |
| 449 | <i>property</i> is a name/value pair. Internally, Fossil implements |
| 450 | tags as properties with a NULL value. So, tags and properties really |
| 451 | are much the same thing, and henceforth we will use the word "tag" |
| @@ -507,15 +491,14 @@ | |
| 507 | [#dist-clone|Above], we stated that forks carry a risk that development |
| 508 | effort on a branch can be divided among the forks. It might not be |
| 509 | immediately obvious why this is so. To see it, consider this swim lane |
| 510 | diagram: |
| 511 | |
| 512 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> |
| 513 | <tr><td align="center"> |
| 514 | <verbatim type="pikchr"> |
| 515 | $laneh = 0.75 |
| 516 | |
| 517 | # Draw the lanes |
| 518 | down |
| 519 | box width 3.5in height $laneh fill 0xacc9e3 |
| 520 | box same fill 0xc5d8ef |
| 521 | box same as first box |
| @@ -573,14 +556,13 @@ | |
| 573 | ellipse same "future" |
| 574 | D3: circle same as B3 at B3-(0,2*$laneh) "3" |
| 575 | arrow 50% |
| 576 | circle same "4" |
| 577 | arrow from D1 to D3 chop |
| 578 | </verbatim> |
| 579 | <br> |
| 580 | Figure 6 |
| 581 | </td></tr></table> |
| 582 | |
| 583 | This is a happy, cooperating team. That is an important restriction on |
| 584 | our example, because you must understand that this sort of problem can |
| 585 | arise without any malice, selfishness, or willful ignorance in sight. |
| 586 | All users on this diagram start out with the same view of the |
| 587 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -2,23 +2,20 @@ | |
| 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" |
| 13 | arrow same |
| 14 | circle same "4"] |
| 15 | box invis "Figure 1" big fit with .n at .3cm below ALL.s |
| 16 | </verbatim> |
| 17 | |
| 18 | Each circle represents a check-in. For the sake of clarity, the check-ins |
| 19 | are given small consecutive numbers. In a real system, of course, the |
| 20 | check-in numbers would be long hexadecimal hashes since it is not possible |
| 21 | to allocate collision-free sequential numbers in a distributed system. |
| @@ -45,23 +42,20 @@ | |
| 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 |
| 53 | circle same "4" at 2nd circle+(.4,-.3) |
| 54 | arrow from 2nd circle to 4th circle chop] |
| 55 | box invis "Figure 2" big fit with .n at .3cm below ALL.s |
| 56 | </verbatim> |
| 57 | |
| 58 | The graph in Figure 2 has two leaves: check-ins 3 and 4. Check-in 2 has |
| 59 | two children, check-ins 3 and 4. We call this state a <i>fork</i>. |
| 60 | |
| 61 | Fossil tries to prevent forks, primarily through its |
| @@ -124,26 +118,23 @@ | |
| 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 |
| 129 | circle same "4" at 2nd circle+(.4,-.3) |
| 130 | arrow from 2nd circle to 4th circle chop |
| 131 | circle same "5" at 3rd circle+(.4,-.3) |
| 132 | arrow from 3rd circle to 5th circle chop |
| 133 | arrow dashed .03 from 4th circle to 5th circle chop] |
| 134 | box invis "Figure 3" big fit with .n at .2cm below ALL.s |
| 135 | </verbatim> |
| 136 | |
| 137 | Check-in 5 is a child of check-in 3 because it was created by editing |
| 138 | check-in 3, but since check-in 5 also inherits the changes from check-in 4 by |
| 139 | virtue of the merge, we say that check-in 5 is a <i>merge child</i> |
| 140 | of check-in 4 and that it is a <i>direct child</i> of check-in 3. |
| @@ -190,14 +181,12 @@ | |
| 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" |
| 192 | arrow same |
| @@ -216,15 +205,13 @@ | |
| 205 | arrow from C6 to C9 chop |
| 206 | arrow dashed 0.03 from C6 to C7 chop |
| 207 | arrow same from C9 to C10 |
| 208 | layer = 0 |
| 209 | box fill 0x9bcdfc color 0x9bcdfc wid (C10.e.x - C2.w.x) ht C6.height*1.5 at C6.c |
| 210 | box invis "test" fit with .sw at last box.sw] |
| 211 | box invis "Figure 4" big with .n at 0 below ALL.s |
| 212 | </verbatim> |
| 213 | |
| 214 | Figure 4 diagrams the following scenario: the project starts and |
| 215 | progresses to a point where (at check-in 2) |
| 216 | it is ready to enter testing for its first release. |
| 217 | In a real project, of course, there might be hundreds or thousands of |
| @@ -404,14 +391,12 @@ | |
| 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 |
| 402 | circle same "3" |
| @@ -438,14 +423,13 @@ | |
| 423 | line color gray from last box.ne to C1 chop |
| 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 | are much the same thing, and henceforth we will use the word "tag" |
| @@ -507,15 +491,14 @@ | |
| 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 | box width 3.5in height $laneh fill 0xacc9e3 |
| 503 | box same fill 0xc5d8ef |
| 504 | box same as first box |
| @@ -573,14 +556,13 @@ | |
| 556 | ellipse same "future" |
| 557 | D3: circle same as B3 at B3-(0,2*$laneh) "3" |
| 558 | arrow 50% |
| 559 | circle same "4" |
| 560 | arrow from D1 to D3 chop |
| 561 | ] |
| 562 | box invis "Figure 6" big fit with .n at 0.2cm below ALL.s |
| 563 | </verbatim> |
| 564 | |
| 565 | This is a happy, cooperating team. That is an important restriction on |
| 566 | our example, because you must understand that this sort of problem can |
| 567 | arise without any malice, selfishness, or willful ignorance in sight. |
| 568 | All users on this diagram start out with the same view of the |
| 569 |