Sat, 07 May 2011 20:22:32 +0200 opener: rename _can_symlink to _cansymlink
Adrian Buehlmann <adrian@cadifra.com> [Sat, 07 May 2011 20:22:32 +0200] rev 14261
opener: rename _can_symlink to _cansymlink
Sun, 08 May 2011 17:48:31 +0200 patch: make patch()/internalpatch() always update the dirstate
Patrick Mezard <pmezard@gmail.com> [Sun, 08 May 2011 17:48:31 +0200] rev 14260
patch: make patch()/internalpatch() always update the dirstate
Sun, 08 May 2011 17:48:30 +0200 patch: move updatedir() from cmdutil into patch
Patrick Mezard <pmezard@gmail.com> [Sun, 08 May 2011 17:48:30 +0200] rev 14259
patch: move updatedir() from cmdutil into patch Also, create an artificial wdutil.py to avoid import cycles between patch.py and cmdutil.py.
Sun, 08 May 2011 17:48:29 +0200 record: unconditionally update the working dir after patching
Patrick Mezard <pmezard@gmail.com> [Sun, 08 May 2011 17:48:29 +0200] rev 14258
record: unconditionally update the working dir after patching
Sun, 08 May 2011 17:48:29 +0200 mq: explicitly updatedir() even if patch() fails
Patrick Mezard <pmezard@gmail.com> [Sun, 08 May 2011 17:48:29 +0200] rev 14257
mq: explicitly updatedir() even if patch() fails It already works that way in practice, and we intend to merge updatedir() into patch().
Fri, 06 May 2011 19:55:46 +0300 mq: allow to qpop/push with a dirty working copy (issue2780)
Idan Kamara <idankk86@gmail.com> [Fri, 06 May 2011 19:55:46 +0300] rev 14256
mq: allow to qpop/push with a dirty working copy (issue2780) It's safe to do so if the sets of changed files in the working copy and patches are disjoint.
Fri, 06 May 2011 19:03:41 +0300 patch: introduce changedfiles
Idan Kamara <idankk86@gmail.com> [Fri, 06 May 2011 19:03:41 +0300] rev 14255
patch: introduce changedfiles returns the set of all changed files in a given patch
Sat, 07 May 2011 23:14:36 +0200 debugindex: change output for generaldelta revlogs
Sune Foldager <cryo@cyanite.org> [Sat, 07 May 2011 23:14:36 +0200] rev 14254
debugindex: change output for generaldelta revlogs For generaldelta revlogs, reporting the deltaparent instead of the chain base makes more sense, since that's what's actually stored in the revlog.
Sat, 07 May 2011 22:40:17 +0200 revlog: support reading generaldelta revlogs
Sune Foldager <cryo@cyanite.org> [Sat, 07 May 2011 22:40:17 +0200] rev 14253
revlog: support reading generaldelta revlogs Generaldelta is a new revlog global flag. When it's turned on, the base field of each revision entry holds the deltaparent instead of the base revision of the current delta chain. This allows for great potential flexibility when generating deltas, as any revision can serve as deltaparent. Previously, the deltaparent for revision r was hardcoded to be r - 1. The base revision of the delta chain can still be accessed as before, since it is now computed in an iterative fashion, following the deltaparents backwards.
Sat, 07 May 2011 22:40:14 +0200 revlog: calculate base revisions iteratively
Sune Foldager <cryo@cyanite.org> [Sat, 07 May 2011 22:40:14 +0200] rev 14252
revlog: calculate base revisions iteratively This is in preparation for generaldelta, where the revlog entry base field is reinterpreted as the deltaparent. For that reason we also rename the base function to chainbase. Without generaldelta, performance is unaffected, but generaldelta will suffer from this in _addrevision, since delta chains will be walked repeatedly. A cache has been added to eliminate this problem completely.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 +30000 tip