Skip to content
Snippets Groups Projects
  1. Dec 06, 2017
  2. Dec 05, 2017
  3. Dec 06, 2017
  4. Dec 05, 2017
  5. Nov 30, 2017
  6. Nov 28, 2017
  7. Nov 23, 2017
  8. Dec 05, 2017
  9. Nov 09, 2017
  10. Oct 04, 2017
  11. Nov 10, 2017
  12. Oct 04, 2017
    • Pulkit Goyal's avatar
      remotenames: add functionality to store remotenames under .hg/hgremotenames/ · 8df8ce2c
      Pulkit Goyal authored
      This patch moves the functionality from remotenames extension to store
      remotenames to core.
      
      Storage format used by remotenames extension:
      
      A single file `.hg/remotenames` with an entry in each line where each line is of
      format:
      `node nametype remotepath/name`
      where nametype is either 'bookmarks' or 'branches'.
      
      This was not the best way to store data, so while moving to core the storage
      format was changed but yet not the final format. The storage format used by core
      after this patch will be:
      
      * A file for each type of name i.e. bookmarks and branches in .hg/remotenames/
        directory
      * A version number on the top of the file. The version for current format is 0.
      * An entry in each line where each line is of the format
      `node\0remotepath\0name`
      
      The logic to sync with existing remotenames file and saving journals and other
      related things will be moved to core in next patches incrementally.
      
      Thanks to Ryan, Augie and Durham for suggestions on storage format.
      
      Previously reviewed as D939.
      
      Differential Revision: https://phab.mercurial-scm.org/D1548
      8df8ce2c
    • Pulkit Goyal's avatar
      remotenames: move function to pull remotenames from the remoterepo to core · 5a629109
      Pulkit Goyal authored
      This patch is the first patch of the series moving functionality from
      hgremotenames extension to core.
      
      There are lot of functionality in the extension which in the end enables us to
      store branch heads and bookmarks location on a server from which we are pulling
      or cloning from. This will help us in creating a better bookmark workflow where
      we can show user that a certain server has this bookmarks at this node. It will
      also introduce namespaces related to remote bookmarks and remote branches.
      
      This patch moves the functionality to pull branches and bookmarks from a
      server from which we are pulling to core behind config option
      `experimental.remotenames`.
      
      This patch adds a test which helps us to analyse whether things are working or
      not. We are currently writing things to ui, we will write information to files
      in upcoming patches.
      
      Previously reviewed as D937.
      
      Differential Revision: https://phab.mercurial-scm.org/D1547
      5a629109
  13. Dec 05, 2017
  14. Nov 30, 2017
  15. Dec 03, 2017
  16. Dec 04, 2017
  17. Nov 25, 2017
  18. Nov 23, 2017
  19. Nov 25, 2017
    • Yuya Nishihara's avatar
      dispatch: alias --repo to --repository while parsing early options · 4edd2202
      Yuya Nishihara authored
      This prepares for replacing old _early*opt() functions. My initial attempt
      was to extend options table to support 'repository|repo' syntax. It worked,
      but seemed too invasive. So I decided to add an optional argument to
      fancyopts() instead.
      
      This also changes the nevernegate dict to be keyed by a canonical_name,
      not by an option-name for clarity.
      4edd2202
  20. Dec 04, 2017
  21. Dec 01, 2017
    • Anton Shestakov's avatar
      hgweb: only include graph-related data in jsdata variable on /graph pages (BC) · d61f2a3d
      Anton Shestakov authored
      Historically, client-side graph code was not only rendering the graph itself,
      but it was also adding all of the changeset information to the page as well.
      It meant that JavaScript code needed to construct valid HTML as a string
      (although proper escaping was done server-side). It wasn't too clunky, even
      though it meant that a lot of server-side things were duplicated client-side
      for no good reason, but the worst thing about it was the data format it used.
      It was somewhat future-proof, but not human-friendly, because it was just a
      tuple: it was possible to append things to it (as was done in e.g.
      270f57d35525), but you'd then have to remember the indices and reading the
      resulting JS code wasn't easy, because cur[8] is not descriptive at all.
      
      So what would need to happen for graph to have more features, such as more
      changeset information or a different vertex style (branch-closing, obsolete)?
      First you'd need to take some property, process it (e.g. escape and pass
      through templatefilters function, and mind the encoding too), append it to
      jsdata and remember its index, then go add nearly identical JavaScript code to
      4 different hgweb themes that use jsdata to render HTML, and finally try and
      forget how brittle it all felt. Oh yeah, and the indices go to double digits if
      we add 2 more items, say phase and obsolescence, and there are more to come.
      Rendering vertex in a different style would need another property (say,
      character "o", "_", or "x"), except if you want to be backwards-compatible, it
      would need to go after tags and bookmarks, and that just doesn't feel right.
      
      So here I'm trying to fix both the duplication of code and the data format:
      
      - changesets will be rendered by hgweb templates the same way as changelog and
        other such pages, so jsdata won't need any information that's not needed for
        rendering the graph itself
      
      - jsdata will be a dict, or an Object in JS, which is a lot nicer to humans and
        is a lot more future-proof in the long run, because it doesn't use numeric
        indices
      
      What about hgweb themes? Obviously, this will break all hgweb themes that
      render graph in JavaScript, including 3rd-party custom ones. But this will also
      reduce the size of client-side code and make it more uniform, so that it can be
      shared across hgweb themes, further reducing its size. The next few patches
      demonstrate that it's not hard to adapt a theme to these changes. And in a
      later series, I'm planning to move duplicate JS code from */graph.tmpl to
      mercurial.js and leave only 4 lines of code embedded in those <script>
      elements, and even that would be just to allow redefining graph.vertex
      function. So adapting a custom 3rd-party theme to these changes would mean:
      
      - creating or copying graphnode.tmpl and adding it to the map file (if a theme
        doesn't already use __base__)
      
      - modifying one line in graph.tmpl and simply removing the bigger part of
        JavaScript code from there
      
      Making these changes in this patch and not updating every hgweb theme that uses
      jsdata at the same time is a bit of a cheat to make this series more
      manageable: /graph pages that use jsdata are broken by this patch, but since
      there are no tests that would detect this, bisect works fine; and themes are
      updated separately, in the next 4 patches of this series to ease reviewing.
      d61f2a3d
  22. Dec 05, 2017
  23. Dec 01, 2017
    • Anton Shestakov's avatar
      hgweb: adopt child nodes in ajaxScrollInit on /graph pages too · fcc96cf0
      Anton Shestakov authored
      ajaxScrollInit is a function that loads more elements (e.g. changelog entries)
      when browser window is scrolled down to the bottom of the page. It basically
      fetches the next page from the server as HTML, finds container element in that
      document and "adopts" (essentially, moves) all its child nodes to the container
      in the current document.
      
      Currently, hgweb doesn't render any changesets on /graph page (everything is
      done in JavaScript), so there are no children to adopt. But there will be soon,
      so let's create a reusable function that does it.
      
      Hardcoding #graphnodes selector is suboptimal, but graph code already does this
      in two other places.
      fcc96cf0
  24. Nov 27, 2017
  25. Nov 17, 2017
Loading