Skip to content
Snippets Groups Projects
  1. Apr 02, 2017
    • Matt Harbison's avatar
      test-subrepo: update output for Windows · 3433bf56
      Matt Harbison authored
      3433bf56
    • Matt Harbison's avatar
      test-serve: disable unfixable tests on Windows · 5e92ba77
      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.
      5e92ba77
    • Matt Harbison's avatar
      test-serve: kill daemons before deleting the access and error logs · 3ed26ba5
      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.
      3ed26ba5
    • Matt Harbison's avatar
      test-serve: make the 'listening at *' lines optional · 594dd384
      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.
      594dd384
  2. Apr 01, 2017
  3. Mar 25, 2017
    • Gregory Szorc's avatar
      show: new extension for displaying various repository data · 264baeef
      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.
      264baeef
  4. Apr 03, 2017
    • Jun Wu's avatar
      test-revlog-raw: remove duplicated option · 15707e58
      Jun Wu authored
      15707e58
    • Jun Wu's avatar
      test-revlog-raw: fix "genbits" implementation · 8a0c4798
      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.
      8a0c4798
  5. Mar 29, 2017
    • Denis Laxalde's avatar
      hgweb: expose a followlines UI in filerevision view · 04ec317b
      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).
      04ec317b
  6. Mar 31, 2017
    • Jun Wu's avatar
      revlog: make _addrevision only accept rawtext · ec48d57d
      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.
      ec48d57d
    • Jun Wu's avatar
      revlog: use raw revisions in clone · 5b93c6fd
      Jun Wu authored
      test-revlog-raw.py now shows "clone test passed", but there is more to fix.
      5b93c6fd
    • Jun Wu's avatar
      revlog: use raw revisions in revdiff · 5d11b5ed
      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.
      5d11b5ed
    • Jun Wu's avatar
      revlog: use raw content when building delta · f424fb18
      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.
      f424fb18
  7. Mar 30, 2017
    • Jun Wu's avatar
      revlog: fix _cache usage in revision() · 2133437d
      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.
      2133437d
  8. Mar 31, 2017
  9. Mar 30, 2017
  10. Mar 29, 2017
  11. Mar 25, 2017
  12. Mar 28, 2017
    • David Soria Parra's avatar
      worker: flush ui buffers before running the worker · 9d3d56aa
      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.
      9d3d56aa
  13. Mar 27, 2017
Loading