Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Clarified User C's view of the bad-fork situation in branching.wiki. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
8a794a5dabdff78f23e09abc946dd2eb |
| User & Date: | wyoung 2019-06-21 12:09:35 |
Context
|
2019-06-21
| ||
| 12:20 | Better internal links in www/branching.wiki to the new "How Can Forks Divide Development Effort?" section. Also added a Wikipedia link for "DVCS". check-in: ed447529 user: wyoung tags: trunk | |
| 12:09 | Clarified User C's view of the bad-fork situation in branching.wiki. check-in: 8a794a5d user: wyoung tags: trunk | |
| 12:04 | More clarity improvements and typo fix in branching.wiki check-in: c16f7cb6 user: wyoung tags: trunk | |
Changes
Changes to www/branching.wiki.
393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 |
depends on why and how that fork occurred. We'll come back to that point later. For now, you can ignore the how and why of it. User B is sync'd with the same view of the repository as User A, so her check-in goes in as a child of the forked check-in 3, that being the latest check-in on the branch at the time. Meanwhile, User C went offline after syncing his repo, so he still sees check-ins 1 and 2 as the latest on the branch. He checks his work in <i>after</i> User B makes her check-in as a child of check-in 2, the latest on that branch at the time User C went offline. User C doesn't learn about check-ins 3 and 4 until after coming back online, syncing, and thus publishing his check-in 5 on the other side of the fork. User D sees all of this, because she comes along after Users A thru C made their check-ins and pushed them to the master repository. Perhaps User D is switching a working directory to this forked branch, or perhaps User D is opening a Fossil repo clone into a new working directory. Regardless, it happens after User C pushed his check-in 5 to the master repo, so User D sees that as the latest on the branch, |
| | | | | | > | |
393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 |
depends on why and how that fork occurred. We'll come back to that point later. For now, you can ignore the how and why of it. User B is sync'd with the same view of the repository as User A, so her check-in goes in as a child of the forked check-in 3, that being the latest check-in on the branch at the time. Meanwhile, User C went offline after syncing his repo with check-in 2 as the latest on that branch. When he checks his changes in, it is as a child of 2, not of 4, because User C doesn't know about 3 & 4 yet. Since he does this at an absolute wall clock time <i>after</i> Users A and B made their check-ins, when User C comes back online and pushes his changes to the master repository — and learns about check-ins 3 and 4 at the same time, during Fossil sync — User C inadvertently revives the other side of the fork. User D sees all of this, because she comes along after Users A thru C made their check-ins and pushed them to the master repository. Perhaps User D is switching a working directory to this forked branch, or perhaps User D is opening a Fossil repo clone into a new working directory. Regardless, it happens after User C pushed his check-in 5 to the master repo, so User D sees that as the latest on the branch, |