Fossil SCM
Small tweaks to previous
Commit
6c2cf0571a45d6d1793a9dcc27f7ad8fe1bdbcc78eae19343587e8ad405c2be3
Parent
9aec171853f9731…
1 file changed
+3
-6
+3
-6
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -383,19 +383,16 @@ | ||
| 383 | 383 | |
| 384 | 384 | All users in this diagram start off with the same two checkins at the |
| 385 | 385 | tip of the working branch, 1 and 2, and they're all working towards some |
| 386 | 386 | indefinite, unified future. This is all happening on some long-lived, |
| 387 | 387 | shared working branch, such as trunk, though it could be anything else |
| 388 | -that matches those same qualifiers. | |
| 389 | - | |
| 390 | -The other key thing to realize in the diagram above is that each user | |
| 391 | -makes only one check-in to set this problem up, that being the one | |
| 392 | -shaded light gray in each swim lane. | |
| 388 | +that matches those same qualifiers. Each user makes only one check-in, | |
| 389 | +shaded light gray. | |
| 393 | 390 | |
| 394 | 391 | User A sets the stage for this problem by creating a fork from check-in |
| 395 | 392 | 1 as check-in 3. Whether what happens as a result is User A's fault |
| 396 | -depends on why and how that branch occurred. We'll come back to that | |
| 393 | +depends on why and how that fork occurred. We'll come back to that | |
| 397 | 394 | point later. For now, you can ignore the how and why of it. |
| 398 | 395 | |
| 399 | 396 | User B is sync'd with the same view of the repository as User A, so her |
| 400 | 397 | check-in goes in as a child of the forked check-in 3, that being the |
| 401 | 398 | latest check-in on the branch at the time. |
| 402 | 399 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -383,19 +383,16 @@ | |
| 383 | |
| 384 | All users in this diagram start off with the same two checkins at the |
| 385 | tip of the working branch, 1 and 2, and they're all working towards some |
| 386 | indefinite, unified future. This is all happening on some long-lived, |
| 387 | shared working branch, such as trunk, though it could be anything else |
| 388 | that matches those same qualifiers. |
| 389 | |
| 390 | The other key thing to realize in the diagram above is that each user |
| 391 | makes only one check-in to set this problem up, that being the one |
| 392 | shaded light gray in each swim lane. |
| 393 | |
| 394 | User A sets the stage for this problem by creating a fork from check-in |
| 395 | 1 as check-in 3. Whether what happens as a result is User A's fault |
| 396 | depends on why and how that branch occurred. We'll come back to that |
| 397 | point later. For now, you can ignore the how and why of it. |
| 398 | |
| 399 | User B is sync'd with the same view of the repository as User A, so her |
| 400 | check-in goes in as a child of the forked check-in 3, that being the |
| 401 | latest check-in on the branch at the time. |
| 402 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -383,19 +383,16 @@ | |
| 383 | |
| 384 | All users in this diagram start off with the same two checkins at the |
| 385 | tip of the working branch, 1 and 2, and they're all working towards some |
| 386 | indefinite, unified future. This is all happening on some long-lived, |
| 387 | shared working branch, such as trunk, though it could be anything else |
| 388 | that matches those same qualifiers. Each user makes only one check-in, |
| 389 | shaded light gray. |
| 390 | |
| 391 | User A sets the stage for this problem by creating a fork from check-in |
| 392 | 1 as check-in 3. Whether what happens as a result is User A's fault |
| 393 | depends on why and how that fork occurred. We'll come back to that |
| 394 | point later. For now, you can ignore the how and why of it. |
| 395 | |
| 396 | User B is sync'd with the same view of the repository as User A, so her |
| 397 | check-in goes in as a child of the forked check-in 3, that being the |
| 398 | latest check-in on the branch at the time. |
| 399 |