Fossil SCM
Typo fix
Commit
d696febb046121af62b4dcdbd363bd80698ea0eb7657f55915eaaaf633ef8a64
Parent
6c2cf0571a45d6d…
1 file changed
+1
-1
+1
-1
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -396,11 +396,11 @@ | ||
| 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 lastest on the branch. When he checks his | |
| 401 | +check-ins 1 and 2 as the latest on the branch. When he checks his | |
| 402 | 402 | latest work in <i>after</i> User B makes her check-in, it's 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 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -396,11 +396,11 @@ | |
| 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 lastest 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 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -396,11 +396,11 @@ | |
| 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 |