- Mar 14, 2011
-
-
Martin Geisler authored
The render_text function actually never existed, the docstring probably meant the render_effects function instead.
-
- Mar 13, 2011
-
-
Martin Geisler authored
-
Klaus Koch authored
-
Benoit Boissinot authored
After a rollback, the current bookmark might be absent from the bookmarks file. In that case we discard it instead of displaying a traceback during commit.
-
Benoit Boissinot authored
-
Steve Borho authored
The win32text extension does not break eol or vice-versa, so it is not a fatal error to have both of them enabled. It's just folly. So spewing warnings in this condition is preferrable to aborting. When both extensions are enabled, the user now sees: % hg st the eol extension is incompatible with the win32text extension win32text is deprecated: http://mercurial.selenic.com/wiki/Win32TextExtension M hgext/eol.py
-
Dirkjan Ochtman authored
-
- Mar 12, 2011
-
-
Benoit Boissinot authored
-
- Mar 13, 2011
-
-
Benoit Boissinot authored
We need to get rid of the previous bookmark after changing current bookmark.
-
Dirkjan Ochtman authored
-
Martin Geisler authored
-
Martin Geisler authored
-
- Mar 12, 2011
-
-
Dirkjan Ochtman authored
-
Dirkjan Ochtman authored
-
Alexander Solovyov authored
-
Alexander Solovyov authored
-
Dirkjan Ochtman authored
-
Alexander Solovyov authored
-
Martin Geisler authored
This fixes a race that was observed when status was called before and after clearing the dirstate.
-
- Mar 10, 2011
-
-
Matt Mackall authored
-
Matt Mackall authored
-
- Mar 09, 2011
-
- Mar 08, 2011
-
-
Steve Borho authored
Not all applications needed the workarounds, so I did not add alternate keys for every Windows merge application.
-
Steve Borho authored
This allows us to provide alternate search keys for 64bit operating systems that may have 32bit merge tools installed. Presumably it may find other uses.
-
Steve Borho authored
Also fixes issue 2658.
-
- Mar 07, 2011
-
-
Patrick Mezard authored
-
Matt Mackall authored
-
- Mar 06, 2011
-
-
David Soria Parra authored
This translation issue was pointed out by Georg Brandl.
-
- Mar 07, 2011
-
-
Eric Eisner authored
-
Matt Mackall authored
This version is about 10% slower, possibly because it visits some revisions in a different topological order than what's in the revlog.
-
- Mar 06, 2011
-
-
Georg Brandl authored
-
- Mar 07, 2011
-
-
Matt Mackall authored
This backs out changeset: 13158:9e7e24052745 user: Mads Kiilerich <mads@kiilerich.com> date: Tue Dec 07 03:29:21 2010 +0100 summary: merge: fast-forward merge with descendant Before named branches, the invariants were: a) "merges" always have two parents b) p1 is not linearly related to p2 Adding named branches made (b) problematic, so the above patch was introduced, which fixed (b) but broke (a). After discussion, we decided that the invariants should be: a) "merges" always have two parents b) p1 is not linearly related to p2 OR p1 and p2 are on different branches
-
- Mar 05, 2011
-
-
Matt Mackall authored
-
- Mar 06, 2011
-
-
Patrick Mezard authored
-
Patrick Mezard authored
-
timeless developer authored
-
timeless developer authored
-
Patrick Mezard authored
Suggested by Antoine Pitrou <pitrou@free.fr>
-
- Mar 05, 2011
-
-
Matt Mackall authored
The following command would visit every changeset in repo/ rather than the last 10: hg log -l 10 repo/
-
- Mar 04, 2011
-
-
Patrick Mezard authored
This happens more often than expected. Say you have an svn subrepository with python code. Python would have generated unknown .pyc files. Now, you rebase this setup on a revision where a directory containing python code does not exist. Subversion is first asked to remove this directory when updating, but will not because it contains untracked items. Then it will have to bring back the directory after the merge but will fail because it now collides with an untracked directory. Using --force is not very elegant but it is much simpler than rewriting our own purge command for subversion.
-