Fossil

Check-in [d696febb]
Login

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

Overview
Comment:Typo fix
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: d696febb046121af62b4dcdbd363bd80698ea0eb7657f55915eaaaf633ef8a64
User & Date: wyoung 2019-06-21 12:01:54
Context
2019-06-21
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
11:57
Small tweaks to previous check-in: 6c2cf057 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
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 lastest 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







|







394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
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