- Apr 22, 2017
-
-
Yuya Nishihara authored
Unlike a mapfile whose template is looked up by spec -> mapfile -> topic, [templates] section is global. We use :sub-section syntax to define parts per template.
-
Yuya Nishihara authored
This seems useful for writing JSON template.
-
Yuya Nishihara authored
templatepartsmap() is a minimal copy of changeset_templater.__init__(). I tried to factor out a common function, but it was unnecessarily complicated.
-
- Mar 15, 2017
-
-
Durham Goode authored
906be86990c4 recently changed to switch from: self._rbcrevs[rbcrevidx:rbcrevidx + _rbcrecsize] = rec to pack_into(_rbcrecfmt, self._rbcrevs, rbcrevidx, node, branchidx) This causes an exception if rbcrevidx is -1 (i.e. the nullrev). The old code handled this because python handles out of bound sets to arrays gracefully. The new code throws because the self._rbcrevs buffer isn't long enough to write 8 bytes to. Normally it would've been resized by the immediately preceding line, but because the 0 length buffer is greater than the idx (-1) times the size, no resize happens. Setting the branch for the nullrev doesn't make sense anyway, so let's skip it. This was caught by external tests in the Facebook extensions repo, but I've added a test here that catches the issue.
-
- Feb 25, 2017
-
-
Yuya Nishihara authored
This is a usage example of fm.context().
-
- Aug 18, 2016
-
-
Yuya Nishihara authored
Before, False was True. This patch fixes the issue by processing True/False transparently. The other values (including integer 0) are tested as strings for backward compatibility, which means "if(latesttagdistance)" never be False. Should we change the behavior of "if(0)" as well?
-
- Aug 05, 2016
-
-
Pierre-Yves David authored
We now attempt to acquire a lock and write the branch cache within that lock. This would prevent cache corruption when multiple processes try to write the cache at the same time.
-
- Jul 18, 2016
-
-
Mads Kiilerich authored
The code used self._rbcnamescount as if it was the length of self._names ... but actually it is just the number of good entries on disk. This caused the cache to be populated inefficiently. In some cases very inefficiently. Instead of checking the length before lookup, just try a lookup in self._names - that is also in most cases faster. Comments and debug messages are tweaked to help understanding the issue and the fix.
-
Mads Kiilerich authored
-
Mads Kiilerich authored
It was in some cases possible to end up writing to the cache file without growing it first. The range assignment in _setcachedata would append instead of writing at the requested position and thus write the new record in the wrong place. To fix this, we avoid looking up in too small caches, and when growing the cache, do it right before writing the new record to it so we know it has been done correctly.
-
Mads Kiilerich authored
-
- Mar 13, 2016
-
-
Mads Kiilerich authored
This should recover automatically from some corruptions that for unknown reasons are seen in the wild.
-
- Feb 08, 2016
-
-
timeless authored
While it is not easy to make a file 000 on Windows, you can emulate most of the behaviors by replacing the file with a directory.
-
- May 22, 2015
-
-
Matt Mackall authored
This warning exists to prevent git users from prematurely polluting their namespace when trying out Mercurial. But for repos that already have multiple branches, understanding what branches are is not optional so we should just shut up.
-
- Feb 25, 2015
-
-
Durham Goode authored
Previously we would only actually write the revbranchcache to disk if we were in the middle of a write operation (like commit). Now we will also write it during any read operation. The cache knows how to invalidate itself, so it shouldn't become corrupt if multiple writers try at once (and the write-on-read behavior/risk is the same as all our other caches).
-
- Mar 17, 2015
-
-
Durham Goode authored
The revbranchecache code already handled the case when the cache file wasn't writable, but let's add a test as well so future changes don't regress this.
-
- Jan 14, 2015
-
-
Mads Kiilerich authored
The cache files are usually append only but will automatically be truncated and recover in exceptional situations. Add a debug notice when such exceptional situations are encountered.
-
Mads Kiilerich authored
The tests that were added with the revision branch cache in 678f53865c68 had suffered from bit rot in the development iterations. They were no longer that "good". Now, the tests are rewritten and reworked to be more readable and maintainable and relevant for the actual implementation. This also utilizes the new 'f' helper tool for keeping an eye the cache files.
-
- Jan 07, 2015
-
-
Mads Kiilerich authored
Branch name filtering in revsets was expensive. For every rev it created a changectx and called .branch() which retrieved the branch name from the changelog. Instead, use the revbranchcache. The revbranchcache is used read-only. The revset implementation with generators and callbacks makes it hard to figure out when we are done using/updating the cache and could write it back. It would also be 'tricky' to lock the repo for writing from within a revset execution. Finally, the branchmap update will usually make sure that the cache is updated before any revset can be run. The revbranchcache is used without any locking but is short-lived and used in a tight loop where we can assume that the changelog doesn't change ... or where it not is relevant to us if it does. perfrevset 'branch(mobile)' on mozilla-central. Before: ! wall 10.989637 comb 10.970000 user 10.940000 sys 0.030000 (best of 3) After, no cache: ! wall 7.368656 comb 7.370000 user 7.360000 sys 0.010000 (best of 3) After, with cache: ! wall 0.528098 comb 0.530000 user 0.530000 sys 0.000000 (best of 18) The performance improvement even without cache come from being based on branchinfo on the changelog instead of using ctx.branch(). Some tests are added to verify that the revbranchcache works and keep an eye on when the cache files actually are updated.
-
- Nov 04, 2014
-
-
Yuya Nishihara authored
Here document should be readable than repeating echo commands.
-
- Oct 02, 2014
-
-
Yuya Nishihara authored
-
Yuya Nishihara authored
Diffs of test output should be harmless. A white space character is moved into "log.changeset" color region.
-
Yuya Nishihara authored
-
- May 02, 2013
-
-
Iulian Stana authored
You can't close a branch that hasn't got a head. newbranch + commit --close-branch must fail newbranch + commit + commit --amend --close-branch must fail You must not be allowed to close a branch that is not defined.
-
- May 07, 2013
-
-
Yuya Nishihara authored
Because dirstate._branch() strips leading/trailing spaces from .hg/branch, "hg branch ' foo '" should abort if branch "foo" exists in another head. tag command had a similar bug and fixed by 3d0a9c8d7184.
-
- Apr 10, 2013
-
-
Mads Kiilerich authored
Backout acd61dc44a39. The changeset prevented closing non-head changesets but did not provide any rationale or test case and I don't see what value it adds. Users might have their reasons to commit something anywhere - and close it immediately. And contrary to the comment that is removed: The topo heads set is _not_ included in the branch heads set of the current branch. It do not include closed topological heads. The change thus prevented closing commits on top of closing commits. A valid usecase for that is to merge closed heads to reduce the number of topological heads. The only existing test coverage for this is the failing double close in test-revset.t. It was added in 3cc2e34d7a7d and seems to not be intentional.
-
- Nov 27, 2012
-
-
Tim Henigan authored
Starting with 361ab1e2086f, users are no longer able to update a working copy to a branch named with a "bad" character (such as ':'). Prior to v2.4, it was possible to create branch names using "bad" characters, so this breaks backwards compatibility. Mercurial must allow users to update to existing branches with bad names. However, it should continue to prevent the creation of new branches with bad names. A test was added to confirm that 'hg update' works as expected. The test uses a bundled repo that was created with an earlier version of Mercurial.
-
- Oct 21, 2012
-
-
Wagner Bruna authored
-
- Oct 18, 2012
-
-
Kevin Bullock authored
This factors out the checks from tags and bookmarks, and newly applies the same prohibitions to branches. checknewlabel takes a new parameter, kind, indicating the kind of label being checked. Test coverage is added for all three types of labels.
-
- Jun 10, 2012
-
-
kiilerix authored
Many tests didn't change back from subdirectories at the end of the tests ... and they don't have to. The missing 'cd ..' could always be added when another test case is added to the test file. This change do that tests (99.5%) consistently end up in $TESTDIR where they started, thus making it simpler to extend them or move them around.
-
- May 07, 2012
-
-
Travis Herrick authored
-
- Dec 08, 2011
-
-
Matt Mackall authored
-
- May 02, 2011
-
-
Peter Arrenbrecht authored
This speeds up the in-memory version of debugbuilddag that I'm working on considerably for the case where we want to build just a 00changelog.i (for discovery tests, for instance). There are a couple of test changes because node ids in tests have changed. The changes to the patch names in test-mq-qdelete.t were required because they could collide with nodeid abbreviations and newly actually do (patch "c" collides with id "cafe..." for patch "b").
-
- Apr 21, 2011
-
-
Danek Duvall authored
Using terminfo instead of hard-coding ECMA-48 control sequences provides a greater assurance that the terminal codes are correct for the current terminal type; not everything supports the ANSI escape codes. It also allows us to use a wider range of colors when a terminal emulator supports it (such as 16- or 256-color xterm), and a few more non-color attributes, such as the ever-popular blink.
-
- Nov 08, 2010
-
-
kiilerix authored
-
- Sep 16, 2010
-
-
Matt Mackall authored
-
- Jul 29, 2010
-
-
Jeremy Whitlock authored
This commit updates the branches command to use ui.label for the branch names and the changeset. This implementation allows assigning colors to the four states of a branch: active, closed, current and inactive. While you can configure color for the four states, only current and closed have default colors of green and black bold respectively.
-
- Aug 14, 2010
-
-
Martin Geisler authored
-
- Feb 11, 2010
-
-
Wagner Bruna authored
Reported as Debian bug #552423.
-
- Jul 01, 2009
-
-
Matt Mackall authored
-