prick 0.2.0

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA256:
+  metadata.gz: 7a41038c7beeb2bb1503ccb199cc45622d6fbe28e113003b98e8e78e10658a37
+  data.tar.gz: 59cb5055863ce2cd63ad9db5a2adf9a0de33d4386bca210dd8e9f25f602bb5e1
+SHA512:
+  metadata.gz: 0b19d6f150e840101f60aa9337583257a0f72e36e2eb7a84b1403063b274099e7a27716aecd2ccaaaf09484a4f5d4b1f9da6eebde340fe9b69da8bab8342528e
+  data.tar.gz: 7b71790136d8de6e2f3c77a58fb5d1e432bbbe6f0c910ada86608e05f759c8ea68d255f1cc038ce2b5efebfb7e379f0bb2f607a94cfd99b5f26cf3665f135130

data/.gitignore

@@ -0,0 +1,28 @@
+/.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
+
+# Temporary ignores
+/releases/
+/migrations/
+/prick.sh
+
+# Ignore bundle binstubs
+/bin/prick

data/.rspec

@@ -0,0 +1,3 @@
+--format documentation
+--color
+--require spec_helper

data/.ruby-version

@@ -0,0 +1 @@
+ruby-2.7.1

data/.travis.yml

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

data/Gemfile

@@ -0,0 +1,6 @@
+source "https://rubygems.org"
+
+git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
+
+# Specify your gem's dependencies in prick.gemspec
+gemspec

data/README.md

@@ -0,0 +1,35 @@
+# Prick
+
+Welcome to your new gem! In this directory, you'll find the files you need to be able to package up your Ruby library into a gem. Put your Ruby code in the file `lib/prick`. To experiment with that code, run `bin/console` for an interactive prompt.
+
+TODO: Delete this and the text above, and describe your gem
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'prick'
+```
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install prick
+
+## Usage
+
+TODO: Write usage instructions here
+
+## Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).
+
+## Contributing
+
+Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/prick.

data/Rakefile

@@ -0,0 +1,6 @@
+require "bundler/gem_tasks"
+require "rspec/core/rake_task"
+
+RSpec::Core::RakeTask.new(:spec)
+
+task :default => :spec

data/bin/console

@@ -0,0 +1,14 @@
+#!/usr/bin/env ruby
+
+require "bundler/setup"
+require "prick"
+
+# You can add fixtures and/or initialization code here to make experimenting
+# with your gem easier. You can also use a different console, if you like.
+
+# (If you use this, don't forget to add pry to your Gemfile!)
+# require "pry"
+# Pry.start
+
+require "irb"
+IRB.start(__FILE__)

data/bin/setup

@@ -0,0 +1,8 @@
+#!/usr/bin/env bash
+set -euo pipefail
+IFS=$'\n\t'
+set -vx
+
+bundle install
+
+# Do any other automated setup that you need to do here

data/doc/create_release.txt

@@ -0,0 +1,17 @@
+
+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

@@ -0,0 +1,98 @@
+
+
+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

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

data/doc/migrations.txt

@@ -0,0 +1,172 @@
+
+
+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

@@ -0,0 +1,116 @@
+
+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