When to Use More Than One Skein

A project can hold as many .skein files as you like. Each is an independent tree with its own engine and seed. Most projects are fine with just default.skein, but a few situations call for more.

How it works

Every .skein file at the project root is a separate skein. Dialog IDE: Run Skein… lists them all for you to choose from, and Dialog IDE: New Skein… creates a new one. Only one session runs at a time, so opening a second skein prompts you to stop the first. The name of the active skein appears in the panel’s tab.

the Run Skein… QuickPick listing several .skein files

Reasons to keep more than one

A clean canonical playthrough.: Keep default.skein as the tidy, fully blessed walkthrough of the project — including the knot labelled WALKTHROUGH that Export Web Page turns into an embedded transcript — and do rough, exploratory testing somewhere else. That keeps the file the web export depends on from filling up with dead ends.
A different seed or engine.: A skein’s engine and random seed are fixed when it is created. To test your project under a different random seed, or to compare the frotz and frotz-release engines against dgdebug, you need a separate skein for each.
Focused regression suites.: One skein per feature or area — combat.skein, parser.skein, endings.skein — keeps each tree small enough to review in a diff, and dgbuild run-skein can replay them all together in a single continuous-integration step (see Command-Line Testing with dgbuild).

Keeping them tidy

Name a skein for what it covers. Commit the skeins you care about — they diff cleanly and belong in version control next to the source. A skein you only spun up for a throwaway experiment does not need to be committed.

What’s next

Building and Releasing Your Project — turning the project into something you can distribute.