prick 0.18.0 → 0.20.2

data/.gitignore

@@ -1,29 +0,0 @@
-/.bundle/
-/.yardoc
-/_yardoc/
-/coverage/
-/rdoc/
-/pkg/
-/spec/reports/
-/tmp/
-/spec/tmp/
-
-# rspec failure tracking
-.rspec_status
-
-# Ignore auto-generated main file
-/main
-
-# Ignore Gemfile.lock. See https://stackoverflow.com/questions/4151495/should-gemfile-lock-be-included-in-gitignore
-/Gemfile.lock
-
-# Put your personal ignore files in /home/clr/.config/git/ignore
-
-# Ignore bundle binstubs
-/bin/prick
-
-# Ignore development testing dir
-/dir
-
-# Ignore stove-away directory
-/hold

data/.travis.yml

@@ -1,7 +0,0 @@
----
-sudo: false
-language: ruby
-cache: bundler
-rvm:
-  - 2.6.6
-before_install: gem install bundler -v 1.17.3

data/doc/create_release.txt

@@ -1,17 +0,0 @@
-
-0.0.0
-  feature_a
-  feature_b
-  feature_c
-
-
-branch 0.0.1.pre.1
-  merge feature_a
-  merge feature_b
-
-
-
-
-
-
-

data/doc/flow.txt

@@ -1,98 +0,0 @@
-
-
-Premises:
-  o When a feature is developed, the release is not known => Features are
-    stored in subdirectories of the base version
-  o Because features are stored in subdirectories of the base version, releases
-    have to live on separate branches to avoid conflicts when two releases
-    use the same base version but different features
-  o As a side-effect a release has a record of previous releases and features
-    in the features/ directory
-  o Features are relatively orthogonal and rarely cause conflicts
-
-  o We want to maintain history => Files are not moved around
-  o We want to support custom releases => Releases lives on branches
-  o We want to be able to shortcircuit the migration chain
-  o We want to be able to bring custom releases back into the main line =>
-    Rebasing lives on separate branches
-  o We want to support semantic versioning
-
-
-Notes:
-  o Referring to a tag gives you a point-in-time. Referring to a branch gives
-    you the newest version
-  o Two kinds of migrations: Feature migrations on new releases and
-    jump-migrations between releases
-
-
-Commands
-  Developer:
-    prick checkout 0.0.0
-    prick feature feature_a
-    prick checkout feature_a-0.0.0
-    work...work...work
-    prick commit
-    prick checkout master
-
-  Release manager:
-    prick checkout 0.0.0
-    prick prepare 0.0.1
-    prick checkout 0.0.1.pre
-    prick merge feature_a-0.0.0 (or 'prick merge feature_a' using lookup by <feature>-<base_version>)
-    
-  Developer:
-    prick checkout 0.0.0
-    prick feature feature_b
-    prick checkout feature_b
-    work...work...work
-    prick commit
-    prick checkout master
-
-  Release manager:
-    prick merge feature_b (conflicts!)
-    asks developer to rebase to current tag
-
-  Developer:
-    prick checkout feature_b
-    prick rebase 0.0.1.pre
-    work...work...work
-    prick commit
-    prick checkout master
-
-  Release manager:
-    prick merge feature_b-0.0.1.pre
-
-
-Different models:
-
-  PER-DIRECTORY-MIGRATION (check)
-    migrations
-      0.0.0/
-      0.0.1/
-      ...
-
-    features/ (not 'releases' because features are nested below the base release)
-      0.0.0/
-        migrate.sql (overrides everything, defaults to calling features.sql)
-        features.sql (list of features in merge-order, maintained by prick)
-        feature_a/
-          merge.sql (contains functions, indexes, and other stuff that doesn't require data migration)
-          migrate.sql (data migrations)
-        feature_b/
-          migrate.sql
-
-      0.0.0-customer/
-        ...
-
-    'feature_a' branch:
-      0.0.0/
-        migrate.sql (auto-generated, calls feature_a/migrate.sql)
-        feature_a/
-          migrate.sql
-
-
-    SHARED-MIGRATION
-      features/
-        0.0.0/
-          migrate.sql
-

data/doc/migra

@@ -1 +0,0 @@
-https://github.com/djrobstep/migra

data/doc/migrations.txt

@@ -1,172 +0,0 @@
-
-
-Each release lives on a branch of it's own and its history will only show
-included features. Development happens on feature branches based on the release
-
-A release lives on a branch because we want to be able to create more than one
-release from a base release with different features and also have a single
-migration file with full history
-
-Features are kept on feature branches and only merged when a release is
-created. The migration.sql file for a feature lives in the directory of the
-base release. Because each feature use the same migration file, the file
-will be merged by git as new features are merged into the release
-
-If a feature is not included in a release, a new migration can be created -
-either using rebase or copy. Rebase is preferred because it maintains history but
-copy allows the feature to be included in other releases based on the original
-
-  migrations/
-    0.0.0/
-      migrate.sql
-          migrate to 0.1.0. We know that because we're on the 0.1.0 branch.
-          Other releases based on 0.0.0 may have different migration files
-
-          prick build & load can build release files for other branches without
-          touching the current branch. This is used when creating migrations
-    0.1.0/
-      migrate-0.0.0.sql
-
-  on a feature branch for 0.1.0
-    0.0.0/
-      migrate.sql <- contain migrations for this feature when based on 0.0.0
-    0.1.0/
-      migrate.sql <- contain migrations for this feature when based on 0.1.0
-
-Problem?
-  0.0.0 -> 0.0.1         -> 0.0.2         ->
-        -> 0.0.1-special -> 0.0.2-special -> 0.0.3
-
-  Der vil være merge conflicts hele vejen ned. Alternativt finde en måde at sige,
-  at den ene branch vinder. Måske forbyde merge af release branches? Og i stedet
-  merge features fra den anden branch manuelt? Til slut kan man lave en migration
-  i hånden fra den anden branch
-
-
-
-DEVELOPER ALICE:
-  create branch alice from 0.0.0
-  work...work...work
-  create migration
-  commit & push
-
-DEVELOPER BOB:
-  create branch bob from 0.0.0
-  work...work...work
-  create migration
-  commit & push
-
-DEVELOPER CHARLOTTE:
-  create branch charlotte from 0.0.0
-  work...work...work
-  create migration
-  commit & push
-  
-RELEASE MANAGER ERIC:
-  set base version to 0.0.0
-  branch to a prerelease 0.1.0. This creates a migration file in the base version
-  merge branch alice (no conflicts). Migration file is 0.0.0/migrate.sql
-  merge branch bob. Merges happens to 0.0.0/migrate.sql
-  mark alice and bob branches as dead
-  merge branch charlotte (conflicts - rolled back)
-  adapt migration file 0.0.0->0.1.0
-  create release 0.1.0
-  0.1.0 is now the new master branch
-  
-DEVELOPER CHARLOTTE:
-  checkout branch charlotte
-  if 0.0.0 feature is not expected to be included in other 0.0.0 based releases
-    rebase to 0.1.0  (no conflicts because 0.1.0 doesn't contain a migration file but probably can't run)
-  else
-    copy to 0.1.0
-  end
-  adapt migration file
-  commit & push
-
-Every branch-release will have a trail of previous releases
-
-
-
-
-
-
-
-
-
-  features/
-    0.0.0/
-      feature_a/
-        migrate.sql 
-      feature_b/
-        migrate.sql # Migrate off 0.0.0
-    0.1.0/ # Includes feature_a
-      migrate-0.0.0.sql # Migrate off 0.0.0
-      feature_b/
-        migrate.sql # Migrate off 0.1.0
-
-Creating a "branch"
-  features/
-    0.0.0/
-      feature_a/
-        migrate.sql
-    0.1.0/
-      migrate-0.0.0.sql
-      feature_b/
-        migrate.sql
-
-
-
-
-
-
-
-
-
-.
-├── 0.0.0
-│   └── migrate.sql
-├── 0.0.1
-│   ├── 0.0.0.sql
-│   └── migrate.sql
-├── 0.0.2
-│   ├── 0.0.1.sql
-│   └── migrate.sql
-├── 0.1.0
-│   └── 0.0.1.sql
-└── migrate.sql
-
-
-0.0.0
-  feature_a
-    migrate.sql
-  feature_b
-    migrate.sql
-
-0.0.1
-  0.0.0.sql <- 0.0.0/feature_a/migrate.sql
-
-rebasing feature_b:
-
-  feature_b
-    migrate.sql
-
-
-
-
-
-
-
-
-
-
-    patches/
-      my-fix-for-something/
-        schemas/
-        migrations/
-          ...
-      my-friends-fix-for-something-else/
-        schemas/
-        migrations/
-          ...
-
-

data/doc/notes.txt

@@ -1,116 +0,0 @@
-
-Git mv link
-  https://linuxctl.com/2016/03/git---preserve-history-when-moving-files/
-
-Upgrade to ruby-2.7
-  gem update --system
-  https://github.com/rubygems/rubygems/issues/3284
-
-Notes
-  o name defaults to
-      - the value of the PRICK_DATABASE environment variable
-      - the name of the current directory
-
-Directory structure
-  Prick uses the following directory structure:
-
-    releases/
-      Contains a <project>-<version>.tar.gz file for each release
-
-    migrations/
-
-      .
-      ├── 0.0.0
-      │   └── migrate.sql
-      ├── 0.0.1
-      │   ├── 0.0.0.sql
-      │   └── migrate.sql
-      ├── 0.0.2
-      │   ├── 0.0.1.sql
-      │   └── migrate.sql
-      ├── 0.1.0
-      │   └── 0.0.1.sql
-      └── migrate.sql
-
-      Migration files are the result of merging in migrations from the branches that this 
-      release includes. They are read-only
-
-      When a migration is created, the migration file from the from-release is copied to 
-      to the to-release directory
-
-
-
-      Each migration directory contains ... 
-        :::here it gets interesting:::
-        o a file listing individual patches for this release (this keeps the git
-          log because we don't have to move individual developer's migration
-          directories around)
-        o a script for resolving conflicting patches. Another option is to make
-          a changes patch/ directory and commit them as part of the git-release
-
-    patches/
-      my-fix-for-something/
-        schemas/
-        migrations/
-          ...
-      my-friends-fix-for-something-else/
-        schemas/
-        migrations/
-          ...
-
-    schemas/
-      prick/
-        Contains the definition of the prick database schema. The schema contains
-        a VERSIONS table and probably a PATCHES table
-
-    tests/
-
-    current/ -> symlink to a unique directory under patches/
-
-    snapshots/
-      Like releases but just a copy of the database
-
-TODO: Keep track of patches in the database when preparing
-
-Developing
-  Make your changes to schemas/ and reload often
-
-  You can generate migrations as you go: 
-
-    change some definitions
-    run 'prick generate migration'
-    modify generated migration file
-    test
-    commit
-
-Preparing
-  Creates a new database with the version number. The database is loaded with 
-  the content of schemas/
-
-  The release is then built by pulling in patches from individual developers
-  and list them in a configuration file. Conflicts can be resolved by a script
-
-Releasing
-  The content of schemas/ is executed on a fresh database and the result is
-  dumped to the releases/ directory. This is the only time a release is saved.
-  A release contains the schema and constant data but not user data
-
-Migrating
-  The current database is updated using the scripts in migrations/
-
-
-
-
-
-
-
-
-
-
-
-
-
-Prick
-  o creates a database and a user at the same time
-  o creates a 'prick' schema in the database with a versions table
-  o uses the unversioned database as work space

data/doc/prick.txt

@@ -1,114 +0,0 @@
-
-
-MIGRATION STATE FILES
-  .prick-migration (State file)
-      version: Version
-        The target version. The result of running the migration on the base
-        release
-      base_version: Version
-        Base version. Running the migration on a base release yields a release
-        of with the same version as the `version` property
-
-      The 0.0.0 version has base_version equal to nil. A Feature has version
-      equal to its base version. 
-      
-      Note that while a release's .prick-migration file lives in the release
-      directory, it's .prick-features file and the migrations lives in the
-      directory of the base release.  This separation supports the
-      single-developer workflow where the next release is not known beforehand
-
-  .prick-features (State file)
-      features: Array
-        A list of features versions
-
-MIGRATION FILES
-  migrate.sql
-  features.sql
-  diff.sql
-
-
-MIGRATION FILE STRUCTURE
-  releases/
-    0.0.0/
-      .prick-migration -> version: 0.0.0, base_version: nil
-      .prick-features -> [feature_a]
-      feature_a/
-        .prick-migration -> version: nil, base_version: 0.0.0
-        .prick-features -> []        
-      feature_b/ (rebased)
-        .prick-migration -> version: 0.2.0, base_version: 0.2.0-pre.1
-        .prick-features -> []
-
-    0.1.0/
-      .prick-migration -> version: 0.1.0, base_version: 0.0.0
-      feature_b/ symlinks to ../0.0.0/feature_b/
-
-    0.1.0/ (wip - single developer work flow)
-      .prick-migration -> version: 0.1.0, base_version: 0.0.0
-      .prick-features -> [feature_c]
-      feature_c/
-        ...
-
-    0.2.0/ (doing a pre-release)
-      .prick-migration -> version: 0.2.0-pre.1, base_version: 0.1.0
-
-  migrations/
-    0.0.0_0.1.0/
-      .prick-migration -> version: 0.1.0, base_version: 0.0.0
-      .prick-features -> []
-
-
-NOTES
-#
-#   Distinguish between running a migration 0.1.0 -> 0.2.0 and running the
-#   migration in the 0.2.0 directory in the single-developer workflow
-#
-#     prick migrate
-#       On a tag: Migrate to that tag
-#       On a branch: Run migrations in the release directory
-#
-#     prick migrate 0.2.0 <- the version number reflects where to find the migration
-#       Runs the migration files in the release directory
-#
-#     prick migrate 0.1.0
-#       Runs the migration files in the base release directory
-#
-#
-#     prick build 
-#       Builds the current schema into the project database
-#
-#     prick build 0.1.0
-#       Builds the given schema into a versioned database
-
-
-
-
-
-
-
-
-
-
-
-
-
-######################
-
-PRICK FILES
-  ./prick-version
-    Contains just one line with the version of the prick command that should be
-    used with this project (eg. 'prick-0.1.0'). Prick checks this file at
-    startup and fails if the required version doesn't match the current command
-
-  ./prick
-      project_name
-        Name of the project
-      
-  ./releases/*/.prick
-      base_version
-        The base version of this release. nil for release 0.0.0
-      features
-        List of features in a release based on this release. Initially empty
-        but filled in when the directory is prepared for a subsequent release.
-        To find the set of features in the current release, inspect the prick
-        file of the base_version in this branch