- Apr 02, 2017
-
-
Matt Harbison authored
-
Matt Harbison authored
These tests would run if hghave.has_serve() were enabled on Windows. Windows has no issue allowing an unpriviledged process to open port 13, so it doesn't abort. The other tests are related to how MSYS tries to be helpful and converts Unix constructs to the Windows equivalent. There isn't any way to disable this behavior, though it supposedly doesn't happen if the exe is linked against the MSYS library.
-
Matt Harbison authored
On Windows, `rm` will fail with 'Permission denied' if another process has it open. It looks like the rollback test was missing the kill entirely.
-
Matt Harbison authored
The daemonized serve process doesn't print these lines out (see 448d0c452140). I was able to get it to with the following hack: diff --git a/mercurial/win32.py b/mercurial/win32.py --- a/mercurial/win32.py +++ b/mercurial/win32.py @@ -418,6 +418,11 @@ return str(ppid) def spawndetached(args): + + import subprocess + return subprocess.Popen(args, cwd=pycompat.getcwd(), env=encoding.environ, + creationflags=subprocess.CREATE_NEW_PROCESS_GROUP).pid + # No standard library function really spawns a fully detached # process under win32 because they allocate pipes or other objects # to handle standard streams communications. Passing these objects However, MSYS translates --prefixes starting with '/' to 'C:/MinGW/msys/1.0', which changes the output. The output isn't so important that I want to spend a bunch of time on this, and risk breaking some subtle behavior of `hg serve -d` with the more complicated code.
-
- Apr 01, 2017
-
-
Matt Harbison authored
The http test simply wasn't updated in 161ab32b44a1 for Windows. It looks like the https test meant to glob away the error message in 3e2d8120528b, but forgot the '*', and was subsequently removed in 408f2202bd80.
-
Matt Harbison authored
Without the quoting, MSYS will remove the '\' directory separators, and the repo can't be opened.
-
Matt Harbison authored
-
- Mar 25, 2017
-
-
Gregory Szorc authored
Currently, Mercurial has a number of commands to show information. And, there are features coming down the pipe that will introduce more commands for showing information. Currently, when introducing a new class of data or a view that we wish to expose to the user, the strategy is to introduce a new command or overload an existing command, sometimes both. For example, there is a desire to formalize the wip/smartlog/underway/mine functionality that many have devised. There is also a desire to introduce a "topics" concept. Others would like views of "the current stack." In the current model, we'd need a new command for wip/smartlog/etc (that behaves a lot like a pre-defined alias of `hg log`). For topics, we'd likely overload `hg topic[s]` to both display and manipulate topics. Adding new commands for every pre-defined query doesn't scale well and pollutes `hg help`. Overloading commands to perform read-only and write operations is arguably an UX anti-pattern: while having all functionality for a given concept in one command is nice, having a single command doing multiple discrete operations is not. Furthermore, a user may be surprised that a command they thought was read-only actually changes something. We discussed this at the Mercurial 4.0 Sprint in Paris and decided that having a single command where we could hang pre-defined views of various data would be a good idea. Having such a command would: * Help prevent an explosion of new query-related commands * Create a clear separation between read and write operations (mitigates footguns) * Avoids overloading the meaning of commands that manipulate data (bookmark, tag, branch, etc) (while we can't take away the existing behavior for BC reasons, we now won't introduce this behavior on new commands) * Allows users to discover informational views more easily by aggregating them in a single location * Lowers the barrier to creating the new views (since the barrier to creating a top-level command is relatively high) So, this commit introduces the `hg show` command via the "show" extension. This command accepts a positional argument of the "view" to show. New views can be registered with a decorator. To prove it works, we implement the "bookmarks" view, which shows a table of bookmarks and their associated nodes. We introduce a new style to hold everything used by `hg show`. For our initial bookmarks view, the output varies from `hg bookmarks`: * Padding is performed in the template itself as opposed to Python * Revision integers are not shown * shortest() is used to display a 5 character node by default (as opposed to static 12 characters) I chose to implement the "bookmarks" view first because it is simple and shouldn't invite too much bikeshedding that detracts from the evaluation of `hg show` itself. But there is an important point to consider: we now have 2 ways to show a list of bookmarks. I'm not a fan of introducing multiple ways to do very similar things. So it might be worth discussing how we wish to tackle this issue for bookmarks, tags, branches, MQ series, etc. I also made the choice of explicitly declaring the default show template not part of the standard BC guarantees. History has shown that we make mistakes and poor choices with output formatting but can't fix these mistakes later because random tools are parsing output and we don't want to break these tools. Optimizing for human consumption is one of my goals for `hg show`. So, by not covering the formatting as part of BC, the barrier to future change is much lower and humans benefit. There are some improvements that can be made to formatting. For example, we don't yet use label() in the templates. We obviously want this for color. But I'm not sure if we should reuse the existing log.* labels or invent new ones. I figure we can punt that to a follow-up. At the aforementioned Sprint, we discussed and discarded various alternatives to `hg show`. We considered making `hg log <view>` perform this behavior. The main reason we can't do this is because a positional argument to `hg log` can be a file path and if there is a conflict between a path name and a view name, behavior is ambiguous. We could have introduced `hg log --view` or similar, but we felt that required too much typing (we don't want to require a command flag to show a view) and wasn't very discoverable. Furthermore, `hg log` is optimized for showing changelog data and there are things that `hg display` could display that aren't changelog centric. There were concerns about using "show" as the command name. Some users already have a "show" alias that is similar to `hg export`. There were also concerns that Git users adapted to `git show` would be confused by `hg show`'s different behavior. The main difference here is `git show` prints an `hg export` like view of the current commit by default and `hg show` requires an argument. `git show` can also display any Git object. `git show` does not support displaying more complex views: just single objects. If we implemented `hg show <hash>` or `hg show <identifier>`, `hg show` would be a superset of `git show`. Although, I'm hesitant to do that at this time because I view `hg show` as a higher-level querying command and there are namespace collisions between valid identifiers and registered views. There is also a prefix collision with `hg showconfig`, which is an alias of `hg config`. We also considered `hg view`, but that is already used by the "hgk" extension. `hg display` was also proposed at one point. It has a prefix collision with `hg diff`. General consensus was "show" or "view" are the best verbs. And since "view" was taken, "show" was chosen. There are a number of inline TODOs in this patch. Some of these represent decisions yet to be made. Others represent features requiring non-trivial complexity. Rather than bloat the patch or invite additional bikeshedding, I figured I'd document future enhancements via TODO so we can get a minimal implmentation landed. Something is better than nothing.
-
- Apr 03, 2017
-
-
Jun Wu authored
-
Jun Wu authored
The "genbits" implementation is actually incorrect. This patch fixes it. A good "genbits" implementation should pass the below assertion: n = 3 # or other number l = list(genbits(n)) assert 2**(n*2) == len(set((l[i]<<n)+l[i+1] for i in range(len(l)-1))) An assertion is added to make sure "genbits" won't work unexpectedly.
-
- Mar 29, 2017
-
-
Denis Laxalde authored
In filerevision view (/file/<rev>/<fname>) we add some event listeners on mouse clicks of <span> elements in the <pre class="sourcelines"> block. Those listeners will capture a range of lines selected between two mouse clicks and a box inviting to follow the history of selected lines will then show up. Selected lines (i.e. the block of lines) get a CSS class which make them highlighted. Selection can be cancelled (and restarted) by either clicking on the cancel ("x") button in the invite box or clicking on any other source line. Also clicking twice on the same line will abort the selection and reset event listeners to restart the process. As a first step, this action is only advertised by the "cursor: cell" CSS rule on source lines elements as any other mechanisms would make the code significantly more complicated. This might be improved later. All JavaScript code lives in a new "linerangelog.js" file, sourced in filerevision template (only in "paper" style for now).
-
- Mar 31, 2017
-
-
Jun Wu authored
All 3 users of _addrevision use raw: - addrevision: passing rawtext to _addrevision - addgroup: passing rawtext and raw=True to _addrevision - clone: passing rawtext to _addrevision There is no real user using _addrevision(raw=False). On the other hand, _addrevision is low-level code dealing with raw revlog deltas and rawtexts. It should not transform rawtext to non-raw text. This patch removes the "raw" parameter from "_addrevision", and does some rename and doc change to make it clear that "_addrevision" expects rawtext. Archeology shows 2df983125d37 added "raw" flag to "_addrevision", follow-ups e12c0fa1f65b and c1b7b2285522 seem to make the flag unnecessary. test-revlog-raw.py no longer complains.
-
Jun Wu authored
test-revlog-raw.py now shows "clone test passed", but there is more to fix.
-
Jun Wu authored
See the added comment. revdiff is meant to output the raw delta that will be written to revlog. It should use raw. test-revlog-raw.py now shows "addgroupcopy test passed", but there is more to fix.
-
Jun Wu authored
Using external content provided by flagprocessor when building revlog delta is wrong, because deltas are applied to raw contents in revlog. This patch fixes the above issue by adding "raw=True". test-revlog-raw.py now shows "local test passed", but there is more to fix.
-
- Mar 30, 2017
-
-
Jun Wu authored
As documented at revlog.__init__, revlog._cache stores raw text. The current read and write usage of "_cache" in revlog.revision lacks of raw=True check. This patch fixes that by adding check about raw, and storing rawtext explicitly in _cache. Note: it may slow down cache hit code path when raw=False and flags=0. That performance issue will be fixed in a later patch. test-revlog-raw now points us to a new problem.
-
- Mar 31, 2017
-
-
Jun Wu authored
There are some issues about revlog raw processing (flag processor). The test is relatively strong covering many cases. It will verify fixes.
-
Pierre-Yves David authored
While we are here, we can also add the hook name information to external hook.
-
Pierre-Yves David authored
The python hooks have access to the hook type information. There is not reason for external hook to not be aware of it too. For the record my use case is to make sure a hook script is configured for the right type.
-
Pierre-Yves David authored
The name used in the message we issue when a hook is untrusted was using "name" which is actually the hook type and not the name of the hook.
-
- Mar 30, 2017
-
-
Pierre-Yves David authored
Hooks related to the transaction are aware of the transaction id. By definition this txn-id is unique and different for each transaction. As a result it can never be predicted in test and always needs matching. As a result, touching any like with this data is annoying. We solve the problem once and for all by installing an automatic replacement. In test, this will now show as: TXNID=TXN:$ID$
-
Ryan McElroy authored
Previously, the pull would succeed, but the subsequent rebase would fail due to the rebase.requiredest flag. Now abort earlier with a more useful error message.
-
Ryan McElroy authored
-
Ryan McElroy authored
-
Ryan McElroy authored
As shown in issue5513, --continue is broken when destination is required. This adds a patch that demonstates this silly behavior, which will be fixed in a future patch.
-
Ryan McElroy authored
We'll be adding a lot more tests here, so it makes sense to have this in its own file now.
-
Denis Laxalde authored
When "patch" query parameter is present in requests to filelog view, line ids in patches diff are no longer unique in the page since several patches are shown on the same page. We now prefix line id by changeset shortnode when several patches are displayed in the same page to have unique line ids overall.
-
- Mar 29, 2017
-
-
Jun Wu authored
Adding new files in the root directory is probably a mistake, and is usually discouraged [1]. The test catches it to avoid mistakes like [2]. Modify the test if files need to be added in the root. [1]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-July/086442.html [2]: https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095836.html
-
Jun Wu authored
-
Jun Wu authored
-
Jun Wu authored
-
Jun Wu authored
revlog.revision takes either node or rev, but taking a rev is more efficient, because converting rev to node is just a seek and read. That's cheaper than converting node to rev, which may require O(n) walk in revlog index for the first times, and then triggering building the radix tree index. Even with the radix tree built, rev -> node is still faster than node -> rev because the radix tree requires more jumps in memory. So r.revision(r.node(rev)) should be changed to r.revision(rev). This patch adds a check-code rule to detect that.
-
Pulkit Goyal authored
-
Denis Laxalde authored
The previous clause for filter out a diff hunk was too restrictive. We need to consider the following cases (assuming linerange=(lb, ub) and the @s2,l2 hunkrange): <-(s2)--------(s2+l2)-> <-(lb)---(ub)-> <-(lb)---(ub)-> <-(lb)---(ub)-> previously on the first and last situations were considered. In test-hgweb-filelog.t, add a couple of lines at the beginning of file "b" so that the line range we will follow does not start at the beginning of file. This covers the change in aforementioned diff hunk filter clause.
-
- Mar 25, 2017
-
-
Denis Laxalde authored
Extend the "parent: " lines in summary to display "(obsolete)" when the parent is obsolete.
-
Denis Laxalde authored
Following respective change in cmdutil.changeset_printer.
-
Denis Laxalde authored
Definition is the same as the one in evolve extension.
-
- Mar 28, 2017
-
-
David Soria Parra authored
a91c62752d08 introduces flushing ui buffers after a worker finished. If the ui was not flushed before the worker was started, fork will copy the existing buffers to the worker. This causes messages issued before the worker started to be written to the terminal for each worker. We are now flushing the ui before we start a worker and add an appropriate test which will fail before this patch.
-
- Mar 27, 2017