Fossil

Check-in [6c2cf057]
Login

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

Overview
Comment:Small tweaks to previous
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 6c2cf0571a45d6d1793a9dcc27f7ad8fe1bdbcc78eae19343587e8ad405c2be3
User & Date: wyoung 2019-06-21 11:57:18
Context
2019-06-21
12:01
Typo fix check-in: d696febb user: wyoung tags: trunk
11:57
Small tweaks to previous check-in: 6c2cf057 user: wyoung tags: trunk
11:50
Clarified the "it doesn't matter how or why" in the previous check-in. check-in: 9aec1718 user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
Figure 6
</td></tr></table>

All users in this diagram start off with the same two checkins at the
tip of the working branch, 1 and 2, and they're all working towards some
indefinite, unified future. This is all happening on some long-lived,
shared working branch, such as trunk, though it could be anything else
that matches those same qualifiers.

The other key thing to realize in the diagram above is that each user
makes only one check-in to set this problem up, that being the one
shaded light gray in each swim lane.

User A sets the stage for this problem by creating a fork from check-in
1 as check-in 3. Whether what happens as a result is User A's fault
depends on why and how that branch 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







|
<
<
<
|



|







381
382
383
384
385
386
387
388



389
390
391
392
393
394
395
396
397
398
399
400
Figure 6
</td></tr></table>

All users in this diagram start off with the same two checkins at the
tip of the working branch, 1 and 2, and they're all working towards some
indefinite, unified future. This is all happening on some long-lived,
shared working branch, such as trunk, though it could be anything else
that matches those same qualifiers. Each user makes only one check-in,



shaded light gray.

User A sets the stage for this problem by creating a fork from check-in
1 as check-in 3. Whether what happens as a result is User A's fault
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