Fossil

Check-in [c16f7cb6]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:More clarity improvements and typo fix in branching.wiki
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: c16f7cb67c42614c1592b06dc6da10b7981d9edc2406c2832873e7a14af60832
User & Date: wyoung 2019-06-21 12:04:57
Context
2019-06-21
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
12:01
Typo fix check-in: d696febb user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
...
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
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. When he checks his
latest work in <i>after</i> User B makes her check-in, it's 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
................................................................................
the other. Some future User E who shows up can end up on either side of
the fork. If User E shows up with the state of the repository as drawn
above, they'll end up on the top side of the fork, because check-in 6 is
the latest, but if User A or B makes a seventh check-in to that branch
first, it will be as a child of check-in 4, and because it's the latest,
User E will end up on the bottom side of the fork instead.

In all of this, relalize that neither side of the fork is obviously
"correct." Every participant was doing the right thing by their own
lights at the time they made their lone check-in. We can only blame User
A for creating the fork if they did so on purpose, as by passing
"--allow-fork" when creating a check-in on a shared working branch. If
the fork was created inadvertently, it's no one's fault.

This is why forks on shared working branches are bad, which is why







|
|







 







|







394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
...
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
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
................................................................................
the other. Some future User E who shows up can end up on either side of
the fork. If User E shows up with the state of the repository as drawn
above, they'll end up on the top side of the fork, because check-in 6 is
the latest, but if User A or B makes a seventh check-in to that branch
first, it will be as a child of check-in 4, and because it's the latest,
User E will end up on the bottom side of the fork instead.

In all of this, realize that neither side of the fork is obviously
"correct." Every participant was doing the right thing by their own
lights at the time they made their lone check-in. We can only blame User
A for creating the fork if they did so on purpose, as by passing
"--allow-fork" when creating a check-in on a shared working branch. If
the fork was created inadvertently, it's no one's fault.

This is why forks on shared working branches are bad, which is why