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
Generated by dwww version 1.15 on Thu May 23 21:01:45 CEST 2024.