Fossil

Check-in [cdd5e576]
Login

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

Overview
Comment:Small fixes to branching.wiki
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: cdd5e576dddb052db3e1a2a2f71cc9e26bd19305ceb5e206973d72cf60a78423
User & Date: wyoung 2019-06-27 23:37:08
Context
2019-06-29
03:08
Enhance the "fossil tag ls" command to allow filtering by tag type. check-in: 971a1a99 user: drh tags: trunk
2019-06-28
07:23
Added the --save-http-url-password option to the clone command to make it skip the "remember password (Y/n)?" prompt if the password was given in an HTTP URL. We avoid this for ssh:// URLs since you have pre-shared keys, SSH agents, and such to avoid the need in that case. Without this feature, you can't script around it by piping "echo y" through the command because the "remember password" feature as of trunk only works when isatty(0), which will be false when Fossil is downstream from a pipe like that. check-in: 2600b771 user: wyoung tags: save-http-url-password
2019-06-27
23:37
Small fixes to branching.wiki check-in: cdd5e576 user: wyoung tags: trunk
23:12
Assorted improvements to the new material in www/branching.wiki, mainly in the way of clarifications and moderation of tone. check-in: 862b77b6 user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

405
406
407
408
409
410
411

412
413
414
415
416
417
418
419
...
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484

All users, except possibly Alan, start out with the same two initial
checkins in their local working clones, 1 & 2. It might be that Alan
starts out with only check-in 1 in his local clone, but we'll deal with
that detail later.

It doesn't matter which branch this happy team is working on, only that

it be a long-lived shared working branch like trunk. Each user makes
only one check-in, shaded light gray in the diagram.

<h3 id="bf-alan">Step 1: Alan</h3>

Alan sets the stage for this problem by creating a
fork from check-in 1 as check-in 3. How and why Alan did this doesn't
affect what happens next, though we will walk through the possible cases
................................................................................
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 even though everyone makes only one check-in
and no one disables autosync without genuine need,
half of the check-ins end up on one side of the fork and half on
the other.







>
|







 







|







405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
...
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485

All users, except possibly Alan, start out with the same two initial
checkins in their local working clones, 1 & 2. It might be that Alan
starts out with only check-in 1 in his local clone, but we'll deal with
that detail later.

It doesn't matter which branch this happy team is working on, only that
our example makes the most sense if you think of it as a long-lived shared
working branch like trunk. Each user makes
only one check-in, shaded light gray in the diagram.

<h3 id="bf-alan">Step 1: Alan</h3>

Alan sets the stage for this problem by creating a
fork from check-in 1 as check-in 3. How and why Alan did this doesn't
affect what happens next, though we will walk through the possible cases
................................................................................
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.

<h3 id="post-mortem">Post Mortem</h3>

The end result of all of this is that even though everyone makes only one check-in
and no one disables autosync without genuine need,
half of the check-ins end up on one side of the fork and half on
the other.