Tcl Library Source Code

Check-in [3226de27a6]
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2019 Conference, Houston/TX, US, Nov 4-8
Send your abstracts to [email protected]
or submit via the online form by Sep 9.

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

Overview
Comment:Bring md list fixes to the devguide.
Timelines: family | ancestors | descendants | both | doc-overhaul
Files: files | file ages | folders
SHA3-256: 3226de27a6f8804b021f73567f74c7124ec6d7e39e807caa8dedee7f51f58b7e
User & Date: aku 2019-03-29 04:22:31
Context
2019-03-29
18:58
Fix old html links in the main index. Go markdown. check-in: 44c6bd8cc3 user: aku tags: doc-overhaul
04:22
Bring md list fixes to the devguide. check-in: 3226de27a6 user: aku tags: doc-overhaul
04:16
Brought md list fixes into the work on the guides check-in: d821fa1849 user: aku tags: doc-overhaul
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to embedded/md/tcllib/files/devdoc/tcllib_devguide.md.

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
    full\-blown sequence \(zig\-zag\) it is *required*, due to the merging from
    trunk\. In the shorter sequence it is only desired\. That said, keeping the
    checkout clean before any major operations is a good habit to have, in my
    opinion\.

    The full\-blown sequencing with checks all the way is to

    Validate the checkout, i\.e\. last commit on your branch\. Run the full test
    suite and other validations, fix all the issues which have cropped up\.


    Merge the latest state of the *trunk* \(see next definition\)\.

    Validate the checkout again\. The incoming trunk changes may have broken
    something now\. Do any required fixes\.

    Now merge to the trunk using

        fossil update trunk
        fossil merge \-\-integrate YOU\_BRANCH

    At this point the checkout should be in the same state as at the end of
    point \(3\) above, because we resolved any issues with the trunk already\. Thus
    a simple

        fossil commit \.\.\.

    should be sufficient now to commit the merge back and close the branch \(due
    to the __\-\-integrate__ we used on the merge\)\.

    The more paranoid may validate the checkout a third time before commiting\.


    I call this a *zig\-zag merge* because of how the arrows look in the
    timeline, from trunk to feature branch for the first merge, and then back
    for the final merge\.

    A less paranoid can do what I call a *simple merge*, which moves step \(2\)
    after step \(4\) and skips step \(3\) entirely\. The resulting shorter sequence
    is

    Validate

    Merge to trunk

    Validate again

    Commit to trunk

    The last step after either zig\-zag or plain merge is to

        fossil sync

    This saves our work to the remote side, and further gives us any other work
    done while we were doing our merge\. It especially allows us to check if we






|
|
>

|

|
|

|

|
|

|
|
|

|

|
|

|
>









|

|

|

|







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
    full\-blown sequence \(zig\-zag\) it is *required*, due to the merging from
    trunk\. In the shorter sequence it is only desired\. That said, keeping the
    checkout clean before any major operations is a good habit to have, in my
    opinion\.

    The full\-blown sequencing with checks all the way is to

      1. Validate the checkout, i\.e\. last commit on your branch\. Run the full
         test suite and other validations, fix all the issues which have cropped
         up\.

      1. Merge the latest state of the *trunk* \(see next definition\)\.

      1. Validate the checkout again\. The incoming trunk changes may have broken
         something now\. Do any required fixes\.

      1. Now merge to the trunk using

             fossil update trunk
             fossil merge \-\-integrate YOU\_BRANCH

      1. At this point the checkout should be in the same state as at the end of
         point \(3\) above, because we resolved any issues with the trunk already\.
         Thus a simple

             fossil commit \.\.\.

         should be sufficient now to commit the merge back and close the branch
         \(due to the __\-\-integrate__ we used on the merge\)\.

         The more paranoid may validate the checkout a third time before
         commiting\.

    I call this a *zig\-zag merge* because of how the arrows look in the
    timeline, from trunk to feature branch for the first merge, and then back
    for the final merge\.

    A less paranoid can do what I call a *simple merge*, which moves step \(2\)
    after step \(4\) and skips step \(3\) entirely\. The resulting shorter sequence
    is

      1. Validate

      1. Merge to trunk

      1. Validate again

      1. Commit to trunk

    The last step after either zig\-zag or plain merge is to

        fossil sync

    This saves our work to the remote side, and further gives us any other work
    done while we were doing our merge\. It especially allows us to check if we