Fossil SCM
Clarified User C's view of the bad-fork situation in branching.wiki.
Commit
8a794a5dabdff78f23e09abc946dd2ebd4d6ff1dae333da5e1655d7c5d5367dc
Parent
c16f7cb67c42614…
1 file changed
+8
-7
+8
-7
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -395,17 +395,18 @@ | ||
| 395 | 395 | |
| 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 | -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. | |
| 400 | +Meanwhile, User C went offline after syncing his repo with check-in 2 as | |
| 401 | +the latest on that branch. When he checks his changes in, it is as a | |
| 402 | +child of 2, not of 4, because User C doesn't know about 3 & 4 yet. Since | |
| 403 | +he does this at an absolute wall clock time <i>after</i> Users A and B | |
| 404 | +made their check-ins, when User C comes back online and pushes his | |
| 405 | +changes to the master repository — and learns about check-ins 3 and 4 at | |
| 406 | +the same time, during Fossil sync — User C inadvertently revives the | |
| 407 | +other side of the fork. | |
| 407 | 408 | |
| 408 | 409 | User D sees all of this, because she comes along after Users A thru C |
| 409 | 410 | made their check-ins and pushed them to the master repository. Perhaps |
| 410 | 411 | User D is switching a working directory to this forked branch, or |
| 411 | 412 | perhaps User D is opening a Fossil repo clone into a new working |
| 412 | 413 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -395,17 +395,18 @@ | |
| 395 | |
| 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 | |
| 408 | User D sees all of this, because she comes along after Users A thru C |
| 409 | made their check-ins and pushed them to the master repository. Perhaps |
| 410 | User D is switching a working directory to this forked branch, or |
| 411 | perhaps User D is opening a Fossil repo clone into a new working |
| 412 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -395,17 +395,18 @@ | |
| 395 | |
| 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 with check-in 2 as |
| 401 | the latest on that branch. When he checks his changes in, it is as a |
| 402 | child of 2, not of 4, because User C doesn't know about 3 & 4 yet. Since |
| 403 | he does this at an absolute wall clock time <i>after</i> Users A and B |
| 404 | made their check-ins, when User C comes back online and pushes his |
| 405 | changes to the master repository — and learns about check-ins 3 and 4 at |
| 406 | the same time, during Fossil sync — User C inadvertently revives the |
| 407 | other side of the fork. |
| 408 | |
| 409 | User D sees all of this, because she comes along after Users A thru C |
| 410 | made their check-ins and pushed them to the master repository. Perhaps |
| 411 | User D is switching a working directory to this forked branch, or |
| 412 | perhaps User D is opening a Fossil repo clone into a new working |
| 413 |