Fossil

Check-in [8a794a5d]
Login

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: 8a794a5dabdff78f23e09abc946dd2ebd4d6ff1dae333da5e1655d7c5d5367dc
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
Hide Diffs Unified Diffs Ignore Whitespace Patch

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,