Fossil SCM
Clarified the "it doesn't matter how or why" in the previous check-in.
Commit
9aec171853f9731773426b6e3255380f3de437c836e4e419e58650d04f7a6755
Parent
efb104bbb112754…
1 file changed
+3
-1
+3
-1
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -390,11 +390,13 @@ | ||
| 390 | 390 | The other key thing to realize in the diagram above is that each user |
| 391 | 391 | makes only one check-in to set this problem up, that being the one |
| 392 | 392 | shaded light gray in each swim lane. |
| 393 | 393 | |
| 394 | 394 | User A sets the stage for this problem by creating a fork from check-in |
| 395 | -1 as check-in 3. It doesn't matter how this happens or why. | |
| 395 | +1 as check-in 3. Whether what happens as a result is User A's fault | |
| 396 | +depends on why and how that branch occurred. We'll come back to that | |
| 397 | +point later. For now, you can ignore the how and why of it. | |
| 396 | 398 | |
| 397 | 399 | User B is sync'd with the same view of the repository as User A, so her |
| 398 | 400 | check-in goes in as a child of the forked check-in 3, that being the |
| 399 | 401 | latest check-in on the branch at the time. |
| 400 | 402 | |
| 401 | 403 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -390,11 +390,13 @@ | |
| 390 | The other key thing to realize in the diagram above is that each user |
| 391 | makes only one check-in to set this problem up, that being the one |
| 392 | shaded light gray in each swim lane. |
| 393 | |
| 394 | User A sets the stage for this problem by creating a fork from check-in |
| 395 | 1 as check-in 3. It doesn't matter how this happens or why. |
| 396 | |
| 397 | User B is sync'd with the same view of the repository as User A, so her |
| 398 | check-in goes in as a child of the forked check-in 3, that being the |
| 399 | latest check-in on the branch at the time. |
| 400 | |
| 401 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -390,11 +390,13 @@ | |
| 390 | The other key thing to realize in the diagram above is that each user |
| 391 | makes only one check-in to set this problem up, that being the one |
| 392 | shaded light gray in each swim lane. |
| 393 | |
| 394 | User A sets the stage for this problem by creating a fork from check-in |
| 395 | 1 as check-in 3. Whether what happens as a result is User A's fault |
| 396 | depends on why and how that branch occurred. We'll come back to that |
| 397 | point later. For now, you can ignore the how and why of it. |
| 398 | |
| 399 | User B is sync'd with the same view of the repository as User A, so her |
| 400 | check-in goes in as a child of the forked check-in 3, that being the |
| 401 | latest check-in on the branch at the time. |
| 402 | |
| 403 |