Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | More clarifications in the "How Can Forks Divide Development Effort?" section of branching.wiki, primarily in explaining how each user in the example arrives at the view shown in the swim lane diagram. There were multiple implicit possilibities before, and some were misinterpreting it. |
---|---|
Downloads: | Tarball | ZIP archive | SQL archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
70a7db80f577f963a5684e52940f92e7 |
User & Date: | wyoung 2019-06-22 03:46:07 |
Context
2019-06-27
| ||
14:39 | Upgrade to openssl 1.1.1c. Use single-argument "expr" in auto.def. Update custom mingw makefile. ... (check-in: 50501328 user: jan.nijtmans tags: trunk) | |
2019-06-22
| ||
03:46 | More clarifications in the "How Can Forks Divide Development Effort?" section of branching.wiki, primarily in explaining how each user in the example arrives at the view shown in the swim lane diagram. There were multiple implicit possilibities before, and some were misinterpreting it. ... (check-in: 70a7db80 user: wyoung tags: trunk) | |
2019-06-21
| ||
13:19 | Gave Users A thru E human names, and humanized their story a bit in the branching.wiki article. ... (check-in: 2ac5bc3c user: wyoung tags: trunk) | |
Changes
Changes to www/branching.wiki.
︙ | ︙ | |||
380 381 382 383 384 385 386 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> <tr><td align="center"> <img src="branch06.svg"><br> Figure 6 </td></tr></table> All users in this diagram start off with the same two checkins at the | > | > | | | | | | | > | | > > > > > > > > > > | > > | | > > > > > > > > > > > > > | | | | | | | | | > | < < > | | | | | | | | > > > | | | > > > > > > > > | > > > < > > > > | > | | > | | 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 | <table border=1 cellpadding=10 hspace=10 vspace=10 align="center"> <tr><td align="center"> <img src="branch06.svg"><br> 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, they're all cloned directly from the same master repository, and they're all working towards some indefinite, unified future. This is a happy, cooperating team, with no malice or selfishness in sight. 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. <a name="bf-alan"></a>Alan sets the stage for this problem by creating a fork from check-in 1 as check-in 3. This has consequences which will occur regardless of how or why that fork occurred, so we can ignore both questions for now. We'll come back to these questions later in [#post-mortem|the <i>post mortem</i> below]. <a name="bf-betty"></a>Because Betty's local clone is autosyncing with the same upstream repository as Alan's clone, there are a number of ways she can end up seeing Alan's check-in 3 as the latest on that branch: <ol> <li><p>The working check-out directory she's using at the moment was on a different branch at the time Alan made check-in 3, so Fossil sees that as the tip at the time she switches her working directory to that branch with a <b>fossil update</b> command. (There is an implicit autosync before <b>update</b> if that option is enabled at the time.)</p></li> <li><p>The same thing, only in a fresh checkout directory with a <b>fossil open $REPO $BRANCH</b> command.</p></li> <li><p>Alan makes his check-in 3 while Betty has check-in 1 or 2 as the tip in her local clone, but because she's working with an autosync'd connection to the same upstream repository as Alan, on attempting what will become check-in 4, she gets the "would fork" message from <b>fossil ci</b>, so she dutifully updates her clone and tries again, moving her work to be a child of the new tip, check-in 3. (If she doesn't update, she creates a <i>second</i> fork, which simply complicates matters beyond what we need here for our illustration.)</p></li> </ol> For our purposes here, it doesn't really matter which one happened. All that matters is that this new branch tip becomes the parent of Betty's check-in 4. <a name="bf-charlie"></a>Meanwhile, Charlie went offline after syncing his repo with check-in 2 as the latest on that branch. When he checks his changes in, it is as a child of 2, not of 4, because Charlie doesn't know about check-ins 3 & 4 yet. He does this at an absolute wall clock time <i>after</i> Alan and Betty made their check-ins, so when Charlie comes back online and pushes his check-in 5 to the master repository and learns about check-ins 3 and 4 during Fossil sync, Charlie inadvertently revives the other side of the fork. <a name="bf-darlene"></a>Darlene sees all of this, because she joins in on the work on this branch after Alan, Betty, and Charlie made their check-ins and pushed them to the master repository. She's taking one of the same three steps as we [#bf-betty|outlined for Betty above]. Regardless of her path to this view, it happens after Charlie pushed his check-in 5 to the master repo, so Darlene sees that as the latest on the branch, causing her work to be saved as a child of check-in 5, not of check-in 4, as it would if Charlie didn't come back online and sync before Darlene started work on that branch up. <h3 id="post-mortem">Post Mortem</h3> The end result of all of this is that everyone makes only one check-in, but half of the check-ins are on one side of the fork, and half are on the other. A future user — his mother calls him Edward, but please call him Eddie — can then join in on the work on this branch and end up on <i>either</i> side of the fork. If Eddie joins in with the state of the repository as drawn above, he'll end up on the top side of the fork, because check-in 6 is the latest, but if Alan or Betty makes a seventh check-in to that branch first, it will be as a child of check-in 4 since that's the version in their local check-out directories. Since that check-in 7 will then be the latest, Eddie will end up on the bottom side of the fork instead. In all of this, realize that neither side of the fork is obviously "correct." Every participant was doing the right thing by their own lights at the time they made their lone check-in. Who, then, is to blame? We can only blame the consequences of creating the fork on Alan if he did so on purpose, as by passing "--allow-fork" when creating a check-in on a shared working branch. Alan might have created it inadvertently by going offline while check-in 1 was the tip of the branch in his local clone, so that by the time he made his check-in 3, check-in 2 had arrived at the shared parent repository from someone else. (Francine?) When Alan rejoins the network and does an autosync, he learns about check-in 2. Since his #3 is already checked into his local clone because autosync was off or blocked, the sync creates an unavoidable fork. We can't blame either Alan or Francine here: they were both doing the right thing given their imperfect view of the state of the global situation. The same is true of Betty, Charlie, and Darlene. None of them tried to create a fork, and none of them chose a side in this fork to participate in. They just took Fossil's default and assumed it was correct. The only blame I can assign here is on any of these users who believed forks couldn't happen before this did occur, and that's for their ignorance. (Which isn't you, dear reader, now.) Any time someone can work without getting full coordination from every other clone of the repo, forks are possible. Given enough time, they're all but inevitable. This sort of consequence is why forks on shared working branches are bad, which is why Fossil tries so hard to avoid them, why it warns you about it when they do occur, and why it makes it relatively quick and painless to fix them when they do occur. <h2>Review Of Terminology</h2> <blockquote><dl> <dt><b>Branch</b></dt> <dd><p>A branch is a set of check-ins with the same value for their |
︙ | ︙ |