Fossil SCM
Small fixes to branching.wiki
Commit
cdd5e576dddb052db3e1a2a2f71cc9e26bd19305ceb5e206973d72cf60a78423
Parent
862b77b69aae9e0…
1 file changed
+3
-2
+3
-2
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -407,11 +407,12 @@ | ||
| 407 | 407 | checkins in their local working clones, 1 & 2. It might be that Alan |
| 408 | 408 | starts out with only check-in 1 in his local clone, but we'll deal with |
| 409 | 409 | that detail later. |
| 410 | 410 | |
| 411 | 411 | It doesn't matter which branch this happy team is working on, only that |
| 412 | -it be a long-lived shared working branch like trunk. Each user makes | |
| 412 | +our example makes the most sense if you think of it as a long-lived shared | |
| 413 | +working branch like trunk. Each user makes | |
| 413 | 414 | only one check-in, shaded light gray in the diagram. |
| 414 | 415 | |
| 415 | 416 | <h3 id="bf-alan">Step 1: Alan</h3> |
| 416 | 417 | |
| 417 | 418 | Alan sets the stage for this problem by creating a |
| @@ -472,11 +473,11 @@ | ||
| 472 | 473 | the same three steps as we [#bf-betty|outlined for Betty above]. |
| 473 | 474 | Regardless of her path to this view, it happens after Charlie pushed his |
| 474 | 475 | check-in 5 to the master repo, so Darlene sees that as the latest on the |
| 475 | 476 | branch, causing her work to be saved as a child of check-in 5, not of |
| 476 | 477 | check-in 4, as it would if Charlie didn't come back online and sync |
| 477 | -before Darlene started work on that branch up. | |
| 478 | +before Darlene started work on that branch. | |
| 478 | 479 | |
| 479 | 480 | <h3 id="post-mortem">Post Mortem</h3> |
| 480 | 481 | |
| 481 | 482 | The end result of all of this is that even though everyone makes only one check-in |
| 482 | 483 | and no one disables autosync without genuine need, |
| 483 | 484 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -407,11 +407,12 @@ | |
| 407 | checkins in their local working clones, 1 & 2. It might be that Alan |
| 408 | starts out with only check-in 1 in his local clone, but we'll deal with |
| 409 | that detail later. |
| 410 | |
| 411 | It doesn't matter which branch this happy team is working on, only that |
| 412 | it be a long-lived shared working branch like trunk. Each user makes |
| 413 | only one check-in, shaded light gray in the diagram. |
| 414 | |
| 415 | <h3 id="bf-alan">Step 1: Alan</h3> |
| 416 | |
| 417 | Alan sets the stage for this problem by creating a |
| @@ -472,11 +473,11 @@ | |
| 472 | the same three steps as we [#bf-betty|outlined for Betty above]. |
| 473 | Regardless of her path to this view, it happens after Charlie pushed his |
| 474 | check-in 5 to the master repo, so Darlene sees that as the latest on the |
| 475 | branch, causing her work to be saved as a child of check-in 5, not of |
| 476 | check-in 4, as it would if Charlie didn't come back online and sync |
| 477 | before Darlene started work on that branch up. |
| 478 | |
| 479 | <h3 id="post-mortem">Post Mortem</h3> |
| 480 | |
| 481 | The end result of all of this is that even though everyone makes only one check-in |
| 482 | and no one disables autosync without genuine need, |
| 483 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -407,11 +407,12 @@ | |
| 407 | checkins in their local working clones, 1 & 2. It might be that Alan |
| 408 | starts out with only check-in 1 in his local clone, but we'll deal with |
| 409 | that detail later. |
| 410 | |
| 411 | It doesn't matter which branch this happy team is working on, only that |
| 412 | our example makes the most sense if you think of it as a long-lived shared |
| 413 | working branch like trunk. Each user makes |
| 414 | only one check-in, shaded light gray in the diagram. |
| 415 | |
| 416 | <h3 id="bf-alan">Step 1: Alan</h3> |
| 417 | |
| 418 | Alan sets the stage for this problem by creating a |
| @@ -472,11 +473,11 @@ | |
| 473 | the same three steps as we [#bf-betty|outlined for Betty above]. |
| 474 | Regardless of her path to this view, it happens after Charlie pushed his |
| 475 | check-in 5 to the master repo, so Darlene sees that as the latest on the |
| 476 | branch, causing her work to be saved as a child of check-in 5, not of |
| 477 | check-in 4, as it would if Charlie didn't come back online and sync |
| 478 | before Darlene started work on that branch. |
| 479 | |
| 480 | <h3 id="post-mortem">Post Mortem</h3> |
| 481 | |
| 482 | The end result of all of this is that even though everyone makes only one check-in |
| 483 | and no one disables autosync without genuine need, |
| 484 |