prick 0.19.0 → 0.20.1

metadata

@@ -1,31 +1,31 @@
 --- !ruby/object:Gem::Specification
 name: prick
 version: !ruby/object:Gem::Version
-  version: 0.19.0
+  version: 0.20.1
 platform: ruby
 authors:
 - Claus Rasmussen
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2021-10-19 00:00:00.000000000 Z
+date: 2022-04-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
-  name: shellopts
+  name: semantic
   requirement: !ruby/object:Gem::Requirement
     requirements:
-    - - '='
+    - - ">="
       - !ruby/object:Gem::Version
-        version: 2.0.0.pre.14
+        version: '0'
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
-    - - '='
+    - - ">="
       - !ruby/object:Gem::Version
-        version: 2.0.0.pre.14
+        version: '0'
 - !ruby/object:Gem::Dependency
-  name: semantic
+  name: indented_io
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
@@ -39,7 +39,7 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
-  name: indented_io
+  name: constrain
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
@@ -53,7 +53,7 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
-  name: boolean
+  name: forward_to
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
@@ -67,7 +67,7 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
-  name: constrain
+  name: bootsnap
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
@@ -81,13 +81,13 @@ dependencies:
       - !ruby/object:Gem::Version
         version: '0'
 - !ruby/object:Gem::Dependency
-  name: developer_exceptions
+  name: ruby-prof
   requirement: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
         version: '0'
-  type: :runtime
+  type: :development
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
@@ -122,6 +122,48 @@ dependencies:
     - - ">="
       - !ruby/object:Gem::Version
         version: '0'
+- !ruby/object:Gem::Dependency
+  name: boolean
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: developer_exceptions
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0'
+- !ruby/object:Gem::Dependency
+  name: shellopts
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 2.0.23
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - "~>"
+      - !ruby/object:Gem::Version
+        version: 2.0.23
 description: A release control and management system for postgresql
 email:
 - claus.l.rasmussen@gmail.com
@@ -130,83 +172,60 @@ executables:
 extensions: []
 extra_rdoc_files: []
 files:
-- ".gitignore"
 - ".rspec"
 - ".ruby-version"
-- ".travis.yml"
 - Gemfile
 - README.md
 - Rakefile
 - TODO
 - bin/console
 - bin/setup
-- doc/create_release.txt
-- doc/flow.txt
-- doc/migra
-- doc/migrations.txt
-- doc/notes.txt
-- doc/prick.txt
-- doc/sh.prick
+- doc/build-yml.txt
 - exe/prick
-- lib/ext/algorithm.rb
-- lib/ext/fileutils.rb
-- lib/ext/forward_method.rb
-- lib/ext/pg.rb
-- lib/ext/shortest_path.rb
+- lib/builder/batch.rb
+- lib/builder/builder.rb
+- lib/builder/node.rb
+- lib/builder/node_pool.rb
+- lib/builder/parser.rb
+- lib/local/command.rb
+- lib/local/git.rb
+- lib/local/timer.rb
 - lib/prick.rb
-- lib/prick/archive.rb
-- lib/prick/branch.rb
-- lib/prick/builder.rb
-- lib/prick/cache.rb
-- lib/prick/command.rb
 - lib/prick/constants.rb
-- lib/prick/database.rb
 - lib/prick/diff.rb
-- lib/prick/dsort.rb
-- lib/prick/ensure.rb
-- lib/prick/exceptions.rb
-- lib/prick/git.rb
-- lib/prick/head.rb
-- lib/prick/migration.rb
-- lib/prick/program.rb
-- lib/prick/project.rb
-- lib/prick/rdbms.rb
-- lib/prick/schema.rb
-- lib/prick/share.rb
+- lib/prick/prick_version.rb
 - lib/prick/state.rb
 - lib/prick/version.rb
-- libexec/strip-comments
-- make_releases
-- make_schema
+- lib/share/init/.gitignore
+- lib/share/init/.prick-context
+- lib/share/init/.rspec
+- lib/share/init/migration/.keep
+- lib/share/init/prick.yml
+- lib/share/init/schema/.keep
+- lib/share/init/schema/build.yml
+- lib/share/init/schema/prick/.keep
+- lib/share/init/schema/prick/build.yml
+- lib/share/init/schema/prick/data.sql
+- lib/share/init/schema/prick/tables.sql
+- lib/share/init/schema/public/.keep
+- lib/share/init/spec/prick_helper.rb
+- lib/share/init/spec/prick_spec.rb
+- lib/share/init/spec/spec_helper.rb
+- lib/share/migrate/migration/build.yml
+- lib/share/migrate/migration/diff.after-tables.sql
+- lib/share/migrate/migration/diff.before-tables.sql
+- lib/share/migrate/migration/diff.tables.sql
+- lib/subcommand/prick-build.rb
+- lib/subcommand/prick-create.rb
+- lib/subcommand/prick-drop.rb
+- lib/subcommand/prick-fox.rb
+- lib/subcommand/prick-init.rb
+- lib/subcommand/prick-make.rb
+- lib/subcommand/prick-migrate.rb
+- lib/subcommand/prick-release.rb
+- lib/subcommand/prick-setup.rb
+- lib/subcommand/prick-teardown.rb
 - prick.gemspec
-- share/diff/diff.after-tables.sql
-- share/diff/diff.before-tables.sql
-- share/diff/diff.tables.sql
-- share/features/diff.sql
-- share/features/feature/diff.sql
-- share/features/feature/migrate.sql
-- share/features/features.sql
-- share/features/features.yml
-- share/features/migrations.sql
-- share/gitignore
-- share/migration/diff.tables.sql
-- share/migration/features.yml
-- share/migration/migrate.sql
-- share/migration/migrate.yml
-- share/migration/tables.sql
-- share/schema/build.yml
-- share/schema/schema.sql
-- share/schema/schema/build.yml
-- share/schema/schema/prick/build.yml
-- share/schema/schema/prick/data.sql
-- share/schema/schema/prick/schema.sql
-- share/schema/schema/prick/tables.sql
-- share/schema/schema/public/.keep
-- share/schema/schema/public/build.yml
-- test_assorted
-- test_feature
-- test_refactor
-- test_single_dev
 homepage: http://www.nowhere.com/
 licenses: []
 metadata: {}
@@ -218,7 +237,7 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: 2.7.1
+      version: '0'
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="

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