Fossil

Check-in [9aec1718]
Login

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

Overview
Comment:Clarified the "it doesn't matter how or why" in the previous check-in.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 9aec171853f9731773426b6e3255380f3de437c836e4e419e58650d04f7a6755
User & Date: wyoung 2019-06-21 11:50:27
Context
2019-06-21
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
11:45
Added "How Can Forks Divide Development Effort?" section to www/branching.wiki. check-in: efb104bb user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

388
389
390
391
392
393
394
395


396
397
398
399
400
401
402
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.  It doesn't matter how this happens or why.



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







|
>
>







388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
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
check-ins 1 and 2 as the lastest on the branch. When he checks his