1. 03 Jun, 2021 3 commits
  2. 02 Jun, 2021 9 commits
    • Georges Racinet's avatar
      Clasic Web UI: preserve line endings in edits of files in Mercurial · 44f6b804e91a
      Georges Racinet authored
      Closes #445
      
      By "classic" here is meant that this is about direct file edit pages,
      not about the Web IDE.
      
      By passing down the `hg_preserver_line_endings` option from the
      controller, we make sure that other call paths to change a file
      content are not affected.
      
      This is covered by a functional test, including the fact that direct
      file uploads are not affected.
      
      --HG--
      branch : heptapod-stable
      44f6b804e91a
    • Georges Racinet's avatar
      WebIDE: preserving line endings for Mercurial repositories · b839ac7b34ea
      Georges Racinet authored
      We're simply using the new `hg_preserve_line_endings` option when
      appropriate.
      
      Of course we don't want to affect only editing done in the UI, because
      the editor normalizes blindly to Unix-style line endings and not
      file uploads (assumed to be the final form and can be binary).
      
      The blob URL condition is really the one to use to make that difference
      between file uploads and editing in the UI: file uploads work in two
      steps: once the file is sent to the server, it is referenced by
      a path starting with `blob:`.
      
      --HG--
      branch : heptapod-stable
      b839ac7b34ea
    • Georges Racinet's avatar
      Commits API: accept `hg_preserve_line_endings` in update action · f37f1bd53a75
      Georges Racinet authored
      The new option goes straight through `MultiService` to the Repository model,
      which is ready to handle it.
      
      This API endpoint is the one used by the Web IDE, which sends lines
      ending in the Unix style. Ultimately, the fact that Web IDE uses the
      most generic endpoint is the reason why we had to introduce a new flag:
      it would otherwise be impossible to make the difference with any other
      client.
      
      --HG--
      branch : heptapod-stable
      f37f1bd53a75
    • Georges Racinet's avatar
      Repository model#multi_actions: handling `hg_preserve_line_endings` · 4513299b2e05
      Georges Racinet authored
      We need to pass it down in Mercurial case and filter it out in Git case
      
      --HG--
      branch : heptapod-stable
      4513299b2e05
    • Georges Racinet's avatar
      HgGitRepository: new `hg_preserve_line_endings` option in file actions · 2a72da81467c
      Georges Racinet authored
      When this obviously mercurial-specific option is present in the
      `update` file action, line endings are preserved with
      
      - normalisation to Unix style if previous content is inconsistent
      - normalisation to Unix style if previous content had no line endings
      
      This is controlled by an option, because we definetely don't want
      all calls (in particular from the remote APIs) to suddenly start changing
      end of lines: our goal is to catch changes made from the Web UIs,
      because they tend to [change ends of lines](#445) if nothing is
      done.
      
      --HG--
      branch : heptapod-stable
      2a72da81467c
    • Georges Racinet's avatar
      Started changelog entry for Heptapod 0.21.4 · b8780276af7b
      Georges Racinet authored
      --HG--
      branch : heptapod-0-21
      b8780276af7b
    • Georges Racinet's avatar
      Bumped GitLab Pages to 1.38.0 · ac8625ef01b7
      Georges Racinet authored
      This is #491 for installations for source: upstream
      1.38.0 fixes the issue and does not seem to introduce
      incompatibilities.
      
      --HG--
      branch : heptapod-0-21
      ac8625ef01b7
    • Georges Racinet's avatar
      Bumped hg-evolve to 10.3.2 · 20e0ef519ba4
      Georges Racinet authored
      Finally found it better to pin it explicitely.
      
      This makes notably the client-side `experimental.auto-publish=abort`
      setting work against Heptapod servers.
      
      Closes #489
      
      --HG--
      branch : heptapod-0-21
      20e0ef519ba4
    • Georges Racinet's avatar
      Merged upstream v13.10.5 · 63ef924dea78
      Georges Racinet authored
      --HG--
      branch : heptapod-0-21
      63ef924dea78
  3. 01 Jun, 2021 2 commits
  4. 31 May, 2021 5 commits
  5. 28 May, 2021 1 commit
    • Georges Racinet's avatar
      Gitlab::Utils: facilitites for line endings · 8baf20b30416
      Georges Racinet authored
      This will help us normalize line endings, with the main target
      to keep previous style on changes made with systems that don't
      respect them (e.g. HTML textareas)
      
      The assumptions is that the *new* content has consistent line
      endings, either Windows or Linux-style, which is the case
      of all current known use-cases. The caller does not have to
      know a priori which style the new content uses (a previous version
      of this patch did, but that turned out inconvenient when a second
      use-case was discovered).
      
      --HG--
      branch : heptapod-stable
      8baf20b30416
  6. 03 Jun, 2021 1 commit
  7. 28 May, 2021 1 commit
    • Georges Racinet's avatar
      Bitbucket Cloud import: avoid conversion to hg · e0504f6b7894
      Georges Racinet authored
      Closes #490
      
      There were two problems
      
      - `:bitbucket`, the identifier for Bitbucket Cloud import,
        wasn't listed as an `:import_type` that forces vcs_type to
        `git`.
      - in that case at least the value is a string, not a symbol.
      
      (end-to-end testing done manually)
      
      --HG--
      branch : heptapod-stable
      e0504f6b7894
  8. 27 May, 2021 4 commits
  9. 26 May, 2021 5 commits
    • GitLab Bot's avatar
      c1b77ff4881b
    • Georges Racinet's avatar
      HgGitRepository: branch/topic introspection only from full hash · db03d43bddea
      Georges Racinet authored
      Because we are now using `--hidden`, symbolic revisions such as
      a bookmark or tag name must be avoided, because of the
      ambiguities that are inherent to them, especially on the unfiltered
      repository.
      
      This is easy to introduce now because it has always been the intent
      for these methods to work on full hashes anyway and that's what
      all current callers do.
      
      The HGitaly equivalent will be more flexible in that regard,
      because its changeset lookup is already able to switch to the
      unfiltered repository only if the requested revision is a full
      changeset ID.
      
      --HG--
      branch : heptapod-stable
      db03d43bddea
    • Georges Racinet's avatar
      Gitlab::Mercurial.full_hex_hash? · 2bf0408e8d8a
      Georges Racinet authored
      Obviously a central utility to tell whether a string is a full
      changeset ID will be useful.
      
      --HG--
      branch : heptapod-stable
      2bf0408e8d8a
    • Georges Racinet's avatar
      HgGitRepository: branch/topic introspection for obsolete changesets · c726b7856bb9
      Georges Racinet authored
      The `hg_changeset_branch` and `hg_changeset_branch_topic` methods
      are called on exact full hexadecimal SHAs only. Our general
      convention in that case (already in use in HGitaly) is that such
      reader methods should just work, because it just means that the
      application stored the hash in one way or another, and that
      accepting obsolete changesets does not bring any ambiguity.
      
      
      Closes #487
      
      --HG--
      branch : heptapod-stable
      c726b7856bb9
    • Georges Racinet's avatar
      Heptapod CI: fixing branch of base image · 4acc1ae03588
      Georges Racinet authored
      --HG--
      branch : heptapod-stable
      4acc1ae03588
  10. 25 May, 2021 2 commits
  11. 20 May, 2021 4 commits
  12. 13 May, 2021 3 commits
    • Georges Racinet's avatar
      Heptapod CI RSpec: added export/import to the regular run · 60813083daab
      Georges Racinet authored
      This is not really cheap, but it makes sense to make really sure
      this is working as expected.
      
      For now, the tests are almost unchanged meaning that it tests
      Git projects, probably working only thanks to the defaulting of
      `vcs_type` to `git` in `VcsTypeRestorer` but we can add some
      specific tests later on.
      
      --HG--
      branch : heptapod-oldstable
      60813083daab
    • Georges Racinet's avatar
      Project import: fixed Mercurial projects · 0245c3d6df73
      Georges Racinet authored
      The only obstacle was the proper initialization of `vcs_type`.
      We previously had to hardcode `git` in `GitLabProjectsImportService`
      and in `CreateService#vcs_type` for `gitlab_project` imports, in order
      for Git imports to work and RSpec tests to succeed, and obviously
      needed to remove that.
      
      Then we introduce a new restoration step, dedicated to reading
      `vcs_type` from the supplied JSON file. It needs to run first, in
      order for the repository restoration steps to do the right thing.
      To avoid duplication, we derive the JSON file location and parsing
      from the general step meant for other attributes, that
      we didn't dare put before the repository steps.
      
      Finally, if the information is absent, we take for granted that
      the export was done on a regular upstream GitLab instance, and hence
      use `git` as a default value, this time from the import itself.
      
      Closes #480
      
      --HG--
      branch : heptapod-oldstable
      0245c3d6df73
    • Georges Racinet's avatar
      Project export: fixed Mercurial projects · 5f4213ac05b6
      Georges Racinet authored
      All that was missing is our bundle producer to return `true` to
      signal success. This is ignored in the case of backups, but is
      essential for project export.
      
      --HG--
      branch : heptapod-oldstable
      5f4213ac05b6