Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Dec 2018 15:59:47 -0800] rev 40857
fastannotate: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D5374
Martin von Zweigbergk <martinvonz@google.com> [Tue, 04 Dec 2018 15:57:11 -0800] rev 40856
debugbuildannotatecache: use progress helper
Differential Revision: https://phab.mercurial-scm.org/D5373
Boris Feld <boris.feld@octobus.net> [Fri, 13 Jul 2018 11:45:15 +0200] rev 40855
upgrade: clarify "aggressivemergedelta" handling
We rename "aggressivemergedelta" argument to "forceaggressivemergedelta". The
previous argument naming could infer an absolute control on the behavior.
However, the code show we respect the config option if set.
Boris Feld <boris.feld@octobus.net> [Fri, 13 Jul 2018 02:54:52 +0200] rev 40854
upgrade: test that fncache is valid after repository upgrade
The behavior was correct. Now it is correct and tested.
Augie Fackler <augie@google.com> [Wed, 05 Dec 2018 12:25:41 -0500] rev 40853
tests: update `rm` invocation for new location of checklink
This should fix the test on FreeBSD.
Differential Revision: https://phab.mercurial-scm.org/D5387
idlsoft <idlsoft@gmail.com> [Mon, 03 Dec 2018 14:17:38 -0500] rev 40852
bookflow: new extension for bookmark-based branching
This extension should be helpful for feature branches - based workflows.
At my company we first considered branches, but weren't sure about creating a lot of permanent objects.
We tried bookmarks, but found some scenarios to be difficult to control.
The main problem, was the active bookmark being moved on update.
Disabling that made everything a lot more predictable.
Bookmarks move on commit, and updating means switching between them.
The extension also implements a few minor features to better guide the workflow:
- hg bookmark NAME can be ambiguous (create or move), unlike hg branch. The extension requires -rev to move.
- require an active bookmark on commit.
- some bookmarks can be protected (like @), useful for teams, that require code reviews.
- block creation of new branches.
The initial implementation requires no changes in the core, but it does rely on some implementation details.
I thought it may be useful to discuss the functionality first, and then focus making the code more robust.
Differential Revision: https://phab.mercurial-scm.org/D4312
Georges Racinet <gracinet@anybox.fr> [Tue, 04 Dec 2018 17:03:43 +0000] rev 40851
rust: make clean takes care of rust/target
This isn't the prettiest way of doing it, but it doesn't require looking
up cargo, or wondering whether that should be part of setup.py clean.
Differential Revision: https://phab.mercurial-scm.org/D5369
Georges Racinet <georges@racinet.fr> [Tue, 04 Dec 2018 14:01:13 +0000] rev 40850
rust: rename local variables in AncestorsIterator::next
It was confusing to have p1 and parents.1 ; (p1, p2) is clearer.
Differential Revision: https://phab.mercurial-scm.org/D5365