Incorporate a "trips" feature

[kevlarr]

Long lists of revisions are pretty cumbersome to reason about, search, etc., especially if I continue to enforce the "no downgrades" thing. It's almost certain that, to get to a final revision state for any given feature, there are likely to be at a minimum 5+ revisions. Even if downgrades are introduced, there are still likely to be several.

And given that revisions are often logically related (ie. a feature release might include 3+ revisions to get to a "final" state), it might make sense to bundle those together.

For example, rather than a structure like...

revisions/
    001.create-users.sql
    002.set-up-user-identities.sql
    003.create-accounts.sql
    004.multi-account-users.sql
    005.some-other-account-thing.sql
    006.comments? oh yeah.sql

... there could be something like...

revisions/
    001.create-users/
        001.1.create-users.sql
        001.2.set-up-user-identities.sql

    002.create-accounts/
        002.1.create-accounts.sql
        002.2.multi-account-users.sql
        002.3.some-other-account-thing.sql

    003.comments? oh yeah.sql

One-off revisions should still be allowed, I think, because...

• It's conceivable that there often can be single-revision "features" (or tasks)
• Backwards compatibility

Some questions...

• Should the tongue-in-cheek language be even more try-hard?
  • ie. revisions can be in "trips" with "steps", or they can be one-off "errands"?
• What should generating a new revision do by default?
• Should hashing and comparison change?
• How to decide which "trip" a revision should be generated for
  • The latest one by default?
  • Or, especially if merging new work into a branch (which could include a later "trip"), always require a trip id?

One novel characteristic of this is that, by viewing the steps in a given trip in relationship to one another, it can be easier to see how a schema changes for a given feature. Additionally, without downgrades, it really clearly shows the iteration within a feature that upgrade/downgrade/repeat cycles can't, but that might not really be a feature (particularly since successive revisions in a 'trip' should be expanding on, rather than fixing, previous steps)