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: |
6c2cf0571a45d6d1793a9dcc27f7ad8f |
| 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
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 |