Fossil SCM
More clarity improvements and typo fix in branching.wiki
Commit
c16f7cb67c42614c1592b06dc6da10b7981d9edc2406c2832873e7a14af60832
Parent
d696febb046121a…
1 file changed
+3
-3
+3
-3
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -396,12 +396,12 @@ | ||
| 396 | 396 | User B is sync'd with the same view of the repository as User A, so her |
| 397 | 397 | check-in goes in as a child of the forked check-in 3, that being the |
| 398 | 398 | latest check-in on the branch at the time. |
| 399 | 399 | |
| 400 | 400 | Meanwhile, User C went offline after syncing his repo, so he still sees |
| 401 | -check-ins 1 and 2 as the latest on the branch. When he checks his | |
| 402 | -latest work in <i>after</i> User B makes her check-in, it's a child of | |
| 401 | +check-ins 1 and 2 as the latest on the branch. He checks his | |
| 402 | +work in <i>after</i> User B makes her check-in as a child of | |
| 403 | 403 | check-in 2, the latest on that branch at the time User C went offline. |
| 404 | 404 | User C doesn't learn about check-ins 3 and 4 until after coming back |
| 405 | 405 | online, syncing, and thus publishing his check-in 5 on the other side of |
| 406 | 406 | the fork. |
| 407 | 407 | |
| @@ -422,11 +422,11 @@ | ||
| 422 | 422 | above, they'll end up on the top side of the fork, because check-in 6 is |
| 423 | 423 | the latest, but if User A or B makes a seventh check-in to that branch |
| 424 | 424 | first, it will be as a child of check-in 4, and because it's the latest, |
| 425 | 425 | User E will end up on the bottom side of the fork instead. |
| 426 | 426 | |
| 427 | -In all of this, relalize that neither side of the fork is obviously | |
| 427 | +In all of this, realize that neither side of the fork is obviously | |
| 428 | 428 | "correct." Every participant was doing the right thing by their own |
| 429 | 429 | lights at the time they made their lone check-in. We can only blame User |
| 430 | 430 | A for creating the fork if they did so on purpose, as by passing |
| 431 | 431 | "--allow-fork" when creating a check-in on a shared working branch. If |
| 432 | 432 | the fork was created inadvertently, it's no one's fault. |
| 433 | 433 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -396,12 +396,12 @@ | |
| 396 | User B is sync'd with the same view of the repository as User A, so her |
| 397 | check-in goes in as a child of the forked check-in 3, that being the |
| 398 | latest check-in on the branch at the time. |
| 399 | |
| 400 | Meanwhile, User C went offline after syncing his repo, so he still sees |
| 401 | check-ins 1 and 2 as the latest on the branch. When he checks his |
| 402 | latest work in <i>after</i> User B makes her check-in, it's a child of |
| 403 | check-in 2, the latest on that branch at the time User C went offline. |
| 404 | User C doesn't learn about check-ins 3 and 4 until after coming back |
| 405 | online, syncing, and thus publishing his check-in 5 on the other side of |
| 406 | the fork. |
| 407 | |
| @@ -422,11 +422,11 @@ | |
| 422 | above, they'll end up on the top side of the fork, because check-in 6 is |
| 423 | the latest, but if User A or B makes a seventh check-in to that branch |
| 424 | first, it will be as a child of check-in 4, and because it's the latest, |
| 425 | User E will end up on the bottom side of the fork instead. |
| 426 | |
| 427 | In all of this, relalize that neither side of the fork is obviously |
| 428 | "correct." Every participant was doing the right thing by their own |
| 429 | lights at the time they made their lone check-in. We can only blame User |
| 430 | A for creating the fork if they did so on purpose, as by passing |
| 431 | "--allow-fork" when creating a check-in on a shared working branch. If |
| 432 | the fork was created inadvertently, it's no one's fault. |
| 433 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -396,12 +396,12 @@ | |
| 396 | User B is sync'd with the same view of the repository as User A, so her |
| 397 | check-in goes in as a child of the forked check-in 3, that being the |
| 398 | latest check-in on the branch at the time. |
| 399 | |
| 400 | Meanwhile, User C went offline after syncing his repo, so he still sees |
| 401 | check-ins 1 and 2 as the latest on the branch. He checks his |
| 402 | work in <i>after</i> User B makes her check-in as a child of |
| 403 | check-in 2, the latest on that branch at the time User C went offline. |
| 404 | User C doesn't learn about check-ins 3 and 4 until after coming back |
| 405 | online, syncing, and thus publishing his check-in 5 on the other side of |
| 406 | the fork. |
| 407 | |
| @@ -422,11 +422,11 @@ | |
| 422 | above, they'll end up on the top side of the fork, because check-in 6 is |
| 423 | the latest, but if User A or B makes a seventh check-in to that branch |
| 424 | first, it will be as a child of check-in 4, and because it's the latest, |
| 425 | User E will end up on the bottom side of the fork instead. |
| 426 | |
| 427 | In all of this, realize that neither side of the fork is obviously |
| 428 | "correct." Every participant was doing the right thing by their own |
| 429 | lights at the time they made their lone check-in. We can only blame User |
| 430 | A for creating the fork if they did so on purpose, as by passing |
| 431 | "--allow-fork" when creating a check-in on a shared working branch. If |
| 432 | the fork was created inadvertently, it's no one's fault. |
| 433 |