Skip to content


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Commits on Jan 6, 2015
  1. Update Pod.

  2. Update script hashes.

    On deploy, if the latest change ID is the same as its script_hash, update the
    script_hashes for all changes in the plan. Items in the database but not the
    plan will have their hashes set to NULL. Changes in the plan but not the
    database of course will not be added to the database until they're deployed.
    Last bit of infrastructure for script hashes as required by the simple merging
    proposed in issue #200.
  3. Silence the running of Vertica registry changes.

    Unless versosity is high.
  4. Catch uninitialized databse errors in current_state().

    Now that we use that funcion to find the latest deployed change, it will be
    run before anything else, and if the databas isn't initialized, it will
    complain. So make sure we catch that error and just return undef.
  5. Get upgrades working on Vertica.

    I forgot that vsql doesn't support `:"variable"` syntax, so use replace such
    `:"registry"` with the proper value for upgrades as well as initializations.
  6. Populate script_hash with change_id on upgrade.

    So that it is easy to tell if the data has been backfilled, since it
    is allowed to be NULL.
  7. No need for that map.

  8. Use try/finally to restore reworked script.

    Seems safer than dealing with scoping issues, which were making tests fail.
  9. Restore file when test finishes.

    Otherwise it ends up with additional lines which I inadvertently commit.
    Relatedly, remove inadvertently-committed lines in said file.
  10. Show more context in error finding change in plan.

    When deploying, that is. Done by using the current state instead of just the
    ID. It fetches more data from the database, but it's not that much (status is
    always fast), and is much more useful for diagnosing problems. Suggested
    by @Ovid (closes #205).
  11. Cache script_hash.

  12. Let script_hash be NULL.

    Because it is allowed to have a change with no deploy script!
Commits on Jan 5, 2015
  1. Add the `script_hash` column to the `changes` table.

    The SHA-1 hash of the deploy script will be stored here. However, since this
    value is not available for all projects during an upgrade, upgraded registries
    will instead get a copy of the change ID. A forthcoming commit will add code
    to update this value on deploy. And in the future, this value will be used to
    help reconcile and merge differences between the plans and registries.
    In order to facilitate testing upgrades, an older version of the schema for
    each engine registry may now be found in `t/lib/upgradable_registries/`. Even
    future engines will need to include this file, with the `script_hash` column
    removed, as well as an upgrade script to add it in a
    `lib/App/Sqitch/Engine/Upgrade/` script.
Commits on Dec 19, 2014
  1. Add the `upgrade` command.

    Closes #87.
  2. Throw an error for a registry of the wrong version.

    Just on deploy and revert for now. Will use _check_registry in other places
    once they need it.
  3. Always upgrade the database.

  4. Add registry updating to the engine.

    It will automatically run an upgrade on `deploy`. This commit includes the
    first upgrade, to 1.0, which is the addition of the `releases` table.
    Had to change the Oracle engine to always `DEFINE` the `registry` variable,
    like Postgres does. Also tweaked the MySQL engine to use the new
    `run_upgrade()` method for the initialization script, and to catch new text
    for a missing table error.
Commits on Dec 18, 2014
  1. Add the `releases` table.

    Will be used to track versions of the registry itself, so that the
    forthcoming `upgrade` command can do its thing.
Commits on Nov 13, 2014
Commits on Nov 5, 2014
Commits on Nov 4, 2014
  1. Increment to v0.998.

  2. Make Inline::C install verbose.

    To try to find out what its problem is.
  3. Update l10n libraries.

  4. Don't migrate core.$engine if engine.$engine exists.

    Instead, emit a warning that `core.$engine` still exists and how to
    remove it. Also note how to remove it after it has been migrated.
Something went wrong with that request. Please try again.