monotone (1.0-1) unstable; urgency=low

  A new package is produced, called monotone-extras, containing a
  tested collection of extra scripts and monotone hooks.

  The hook 'get_netsync_key' has been split upstream into two separate
  hooks, 'get_netsync_client_key' and 'get_netsync_server_key'.
  Please notify the users that they will need to change their custom
  hooks to accommodate this change.

  The database format has changed slightly upstream, for speed
  improvements.  You need to do the following on each of your
  databases after taking a backup of the (except for the server
  database handled by the monotone-server package, for which it is
  done automatically):

        mtn db migrate

  No "flag day" is needed for this, you do not have to upgrade at the
  same time as everyone else in your projects.

  For more information, please read the upstream NEWS file.

 -- Richard Levitte <richard@levitte.org>  Mon, 21 Feb 2011 03:59:13 +0100

monotone (0.99.1-1) UNRELEASED; urgency=low

  * Upstream made major changes, for speed, usability and more.  This may
    disrupt some script, as some commands and options have been changed as
    well as the output of some commands.  See NEWS and UPGRADE for full
    details.

    The database format has changed slightly.  You need to do the following
    on each of your databases after taking a backup of the (except for the
    server database handled by the monotone-server package, for which it is
    done automatically):

        mtn db migrate

    No "flag day" is needed for this, you do not have to upgrade at the
    same time as everyone else in your projects.

 -- Richard Levitte <richard@levitte.org>  Thu, 11 Nov 2010 13:17:33 +0100

monotone (0.45-1) unstable; urgency=low

  * The fix for bug #542287 changes the default run-levels in which
    the monotone server is started, and may overwrite local customizations
    to those run-levels in some cases.  If you use the monotone-server
    package and you changed the /etc/rc*.d links for it, check after
    upgrade to make sure they are the way you want them.

  * Upstream made major changes to key handling: certs now refer to
    the key that signed them by hash, not name.  This permits some
    significant security and usability improvements: for instance, it
    is now possible to retire an old key without changing to a new
    email address.  See NEWS and UPGRADE for full details.

    There is no "flag day" for this: you do not have to upgrade at the
    same time as everyone else in your projects.  However, if you have
    more than one public key in your database with the same name,
    older clients will not be able to process all of the certs signed
    with those keys.

    The database format did change.  You need to do the following on
    each of your databases after taking a backup of them (except for
    the server database handled by the monotone-server package, for
    which it is done automatically):

    	mtn db migrate

 -- Zack Weinberg <zackw@panix.com>  Sat, 14 Nov 2009 12:38:19 -0800

monotone (0.40-1) unstable; urgency=low

  * The database format has changed for efficiency.  You need to do the
    following on each of your databases after taking a backup of them
    (except for the server database handled by the monotone-server
    package, for which it is done automatically):

    	mtn db migrate

 -- Richard Levitte <richard@levitte.org>  Thu, 03 Apr 2008 16:55:36 +0200

monotone (0.31-90.2) unstable; urgency=low

  * "mtn serve" doesn't take any mandatory arguments any more.  Instead
    of specifying branches to serve (or to exclude) on the command line,
    mtn now entirely trusts the netsync permission hooks called
    get_netsync_read_permitted and get_netsync_write_permitted.

    If you have any "mtn serve" still running with branches given on the
    command line, you will need to remove those and work on the hooks.
    If you just have the argument "*", it can safely be removed.  Not
    doing so will cause your server to stop working.

 -- Richard Levitte <richard@levitte.org>  Sat, 18 Nov 2006 22:35:15 +0100

monotone (0.31-90.1) unstable; urgency=low

  * Another efficiency change.  You need to do the following on each
    of your databases (except for the server database handled by the
    monotone-server package, for which this is done automatically):

        mtn db migrate
        # ... possibly other commands, depending on how old your previous
        #     mtn version was
        mtn db regenerate_caches

    This does NOT affect remote participants of your projects, the
    changes are only local.

 -- Richard Levitte <richard@levitte.org>  Mon, 13 Nov 2006 22:56:10 +0100

monotone (0.30-0.1) unstable; urgency=low

  * Efficiency changes have been implemented, which changes the rosters
    (and internal file description structure).  It means that you will
    have to do the following on each of your databases (except for the
    server database handled by the monotone-server package, for which
    this is done automatically):

        mtn db migrate
        # ... possibly other commands, depending on how old your previous
        #     mtn version was
        mtn db regenerate_rosters

    This does NOT affect remote participants of your projects, the
    changes are only local.

 -- Richard Levitte <richard@levitte.org>  Thu,  7 Sep 2006 05:15:43 +0200

monotone (0.30-0.1) unstable; urgency=low

  * [this is copied from the normal monotone NEWS file]

        In this release, there is a minor change to the format of the
        data stored in the bookkeeping directory "_MTN".  You must run
        the command "mtn migrate_workspace" in all your existing
        workspaces before you can use them with this version of
        monotone; once you have done this, you will not be able to use
        those workspaces with older versions of monotone.  Nothing
        terrible will happen if you try to use an old workspace
        without migrating it; you'll just get an error message.

        This change makes it possible for a workspace to have more
        than one parent revision, which will enable a number of
        long-wanted features.  Those features are not yet complete,
        but we do not expect to have to change formats again to
        support them.

 -- Richard Levitte <richard@levitte.org>  Tue,  5 Sep 2006 08:18:34 +0200
