mercurial (1.4.3-1) unstable; urgency=low

  mercurial.el (emacs mode for mercurial) is not installed anymore in emacs
  paths. Emacs22 or newer has vc-hg.el that is better. If needed, this file
  is still provided in the examples directory.
    The alias extension does not exist anymore as its functionalities are now
  in mercurial core. To avoid spurious warning about failed loading of
  extension, users just have to remove it in their hgrc file.

 -- Vincent Danjean <vdanjean@debian.org>  Mon, 15 Feb 2010 18:06:52 +0100

mercurial (1.1.2-1) unstable; urgency=low

  Since the 1.1.2-1 version, mercurial does not enable any extension by
  default anymore. Upstream asks us to do so because:
  - users can easily enable any extension if they wish, however they cannot
    disable a extension that have been enabled system-wide
  - upstream prefers that default Mercurial installation is the plain Mercurial
    without extension.

 -- Vincent Danjean <vdanjean@debian.org>  Sat, 17 Jan 2009 17:47:06 +0100

mercurial (1.0-5) unstable; urgency=low

  Since the 1.0 version, mercurial handles most of the merges internaly.
  This is an upstream decision (see upstream changeset f077815932ce)
  that the debian package will follow. This means that :
  - there is no hgmerge script any more
  - programs that were invoked by hgmerge (kdiff3, ...) are not by default
  See http://www.selenic.com/mercurial/wiki/index.cgi/MergeToolConfiguration
  for configuring mergetools with mercurial 1.0

 -- Vincent Danjean <vdanjean@debian.org>  Tue, 20 May 2008 22:37:24 +0200

mercurial (1.0) unstable; urgency=low

  Since the 1.0 version, the hbisect extension is now provided as a 
  built-in command. If you keep an older version of the hgext.rc file
  in /etc/mercurial/hgrc.d/ or a $HOME/.hgrc file with the extension 
  enabled , mercurial will emit a warning: "failed to import extension 
  hgext.hbisect: No module  named  hbisect". Just delete the  
  hgext.hbisect entry in the hgext.rc and/or .hgrc file.
  
 -- Gerardo Curiel <gcuriel@debian.org.ve>  Wed, 02 Apr 2008 16:14:47 -0430

mercurial (0.9) unstable; urgency=low

  Since the 0.8.1-5 version, mercurial uses python2.4 instead of (currently the
  default on Debian system) python2.3. This allows tailor to use the hg
  backend (tailor requires python2.4).
  If someone really need python2.3 version of mercurial, please tell me (with
  reportbug for example). I will then split the package in python modules
  (default, 2.3, 2.4, ...) and one executable.

  Note: if you copied the hgwebdir.cgi or hgweb.cgi script from the examples
  directory, do not forget to update it so that it runs /usr/bin/python2.4
  instead of /usr/bin/python (or recopy it)

  UPDATE since 0.9-6:
    Due to the new python policy, mercurial modules are now available for all
  supported python versions in debian (currently 2.3 and 2.4)

 -- Vincent Danjean <Vincent.Danjean@ens-lyon.org>  Tue,  4 Jul 2006 00:53:21 +0200

mercurial (0.8) unstable; urgency=low
  Upgrade notes:
  - diff and status command are now repo-wide by default
    (use 'hg diff .' for the old behavior)
  - GPG signing is now done with the gpg extension
  - the --text option for commit, rawcommit, and tag has been removed
  - the copy/rename --parents option has been removed

 -- Vincent Danjean <Vincent.Danjean@ens-lyon.org>  Mon, 30 Jan 2006 16:11:19 +0100

mercurial (0.6c-1) unstable; urgency=low

  Previous versions of mercurial can lead to conflicts for internal filenames
  if the repo has both a file 'foo' and a directory 'foo.d'.
  This version of mercurial solves this, however this means that some internal
  files have been renamed.

  If you want to use (commit, clone on same filesystem, ...) a repo created
  with an old version with the new version AND this repo contains directory
  nammed 'foo.d', then you need to deal with it. According to the upstream
  author, something like this should do the trick:

   find .hg -type d -name "*.[di]" -exec echo mv {} {}.hg ";"

  Run this at the top of your working dir. Take out the 'echo' once
  you've confirmed it's finding the right files.

  Also note that 0.6c and older clients should be perfectly compatible
  over the wire, so long as each side has the appropriate directory
  naming.

  But if you use 0.6c to pull into a repo created by 0.6b with changes
  that touch files in an affected directory, you're likely to have
  strange behavior.

 -- Vincent Danjean <Vincent.Danjean@ens-lyon.org>  Tue, 23 Aug 2005 09:55:35 +0200
