1. 15 Dec, 2020 1 commit
  2. 25 Nov, 2020 1 commit
  3. 30 Oct, 2020 1 commit
  4. 25 Oct, 2020 1 commit
    • Georges Racinet on mutations.racinet.fr's avatar
      Commit: introducing hpd_display_id · b10c60a26265
      In some cases it makes sense to display a different commit ID than the
      one used for addressing. Of course our existing `HgGitRepository` is
      a prime example of that, but it's not hard to imagine other ones.
      
      Up to now, we've changed some templates and user-facing to code to
      use directly some 'hgid'. For dual VCS support, as well as intermediate
      steps towards Mercurial native support, we'll need something more
      abstract than that.
      
      The method name, `hpd_display_id`, is voluntary obnoxious: we want
      to recognize at first glance that it's Heptapod-specific, and we want
      it to be easy to find all occurrences in the code base, in preparation
      for potential future times when we won't be needing it any more.
      
      --HG--
      branch : heptapod
      b10c60a26265
  5. 26 Oct, 2020 1 commit
  6. 25 Oct, 2020 1 commit
  7. 19 Oct, 2020 2 commits
  8. 18 Oct, 2020 1 commit
    • Georges Racinet's avatar
      HgGitRepository#hg_pull · 667641b1a538
      Georges Racinet authored
      This will be an interesting low-level helper, being exposed
      on the `Repository` model automatically, like all "raw"
      repository methods.
      
      Like all write methods, a valid `user` argument must be passed.
      
      --HG--
      branch : heptapod
      667641b1a538
  9. 27 Aug, 2020 3 commits
    • Georges Racinet's avatar
      Forwarding actual permissions to Mercurial processes · 4c45dfe84231
      Georges Racinet authored
      Closes #334
      
      Normally, the abstraction layers in GitLab mean that the Project
      should not be accessible from the low level repository. However,
      we need it to pass it down to the `hg` processes. Doing it in
      `hg_env_for_write` is the way to make it really robust, since all
      write operations basically have to use it.
      
      To mitigate somewhat this breach of abstraction, we make the
      attribute writable only, and we give it a more specific name than
      just '@project'. Aesthetically, it would be better to store only
      a factory for the `UserAccess` instance that we really need, but
      that could be done separately.
      
      This required running some of `HgAccess` RSpec tests with empty
      repositories, because in them, the project owner does not have enough
      rights to create a first commit any more, and there's not even
      an admin user around for that.
      
      --HG--
      branch : heptapod
      4c45dfe84231
    • Georges Racinet on mutations.racinet.fr's avatar
      d1aba8b71579
    • Georges Racinet on mutations.racinet.fr's avatar
      HgGitRepository: attribute to skip Git hooks for tests · db821ec4ea3f
      This new attribute is not meant to be used in any other context
      than RSpec tests, whence the name. It allows us to use higher
      level methods such as `multi_action` in tests setups and will be
      necessary to test them.
      
      Upstream does something similar with no need to involve the tested code:
      they launch Gitaly server with the `GITALY_TESTING_NO_GIT_HOOKS` environment
      variable.
      
      --HG--
      branch : heptapod
      db821ec4ea3f
  10. 26 Aug, 2020 1 commit
  11. 19 Jul, 2020 1 commit
    • Georges Racinet's avatar
      First rspec tests for HgGitRepository · d907e80d79a1
      Georges Racinet authored
      They don't do much, but it's a start.
      
      An important piece of information is that this
      works right away on a HDK setup by running
      
      ```
      bin/rspec spec/lib/gitlab/mercurial
      ```
      
      In particular, the test harness does start a Gitaly
      server (and also Workhorse, but these repository
      tests don't need it)
      
      --HG--
      branch : heptapod
      d907e80d79a1