BigW Consortium Gitlab

  1. 28 Nov, 2017 1 commit
    • Ensure MRs always use branch refs for comparison · 3c6a4d63
      Sean McGivern authored
      If a merge request was created with a branch name that also matched a tag name,
      we'd generate a comparison to or from the tag respectively, rather than the
      branch. Merging would still use the branch, of course.
      
      To avoid this, ensure that when we get the branch heads, we prepend the
      reference prefix for branches, which will ensure that we generate the correct
      comparison.
  2. 23 Nov, 2017 1 commit
    • Use latest_merge_request_diff association · 991bf24e
      Sean McGivern authored
      Compared to the merge_request_diff association:
      
      1. It's simpler to query. The query uses a foreign key to the
         merge_request_diffs table, so no ordering is necessary.
      2. It's faster for preloading. The merge_request_diff association has to load
         every diff for the MRs in the set, then discard all but the most recent for
         each. This association means that Rails can just query for N diffs from N
         MRs.
      3. It's more complicated to update. This is a bidirectional foreign key, so we
         need to update two tables when adding a diff record. This also means we need
         to handle this as a special case when importing a GitLab project.
      
      There is some juggling with this association in the merge request model:
      
      * `MergeRequest#latest_merge_request_diff` is _always_ the latest diff.
      * `MergeRequest#merge_request_diff` reuses
        `MergeRequest#latest_merge_request_diff` unless:
          * Arguments are passed. These are typically to force-reload the association.
          * It doesn't exist. That means we might be trying to implicitly create a
            diff. This only seems to happen in specs.
          * The association is already loaded. This is important for the reasons
            explained in the comment, which I'll reiterate here: if we a) load a
            non-latest diff, then b) get its `merge_request`, then c) get that MR's
            `merge_request_diff`, we should get the diff we loaded in c), even though
            that's not the latest diff.
      
      Basically, `MergeRequest#merge_request_diff` is the latest diff in most cases,
      but not quite all.
  3. 13 Nov, 2017 1 commit
  4. 11 Nov, 2017 1 commit
  5. 06 Nov, 2017 1 commit
  6. 03 Nov, 2017 1 commit
  7. 27 Oct, 2017 2 commits
    • Cache commits on the repository model · 3411fef1
      Zeger-Jan van de Weg authored
      Now, when requesting a commit from the Repository model, the results are
      not cached. This means we're fetching the same commit by oid multiple times
      during the same request. To prevent us from doing this, we now cache
      results. Caching is done only based on object id (aka SHA).
      
      Given we cache on the Repository model, results are scoped to the
      associated project, eventhough the change of two repositories having the
      same oids for different commits is small.
  8. 13 Oct, 2017 1 commit
  9. 11 Oct, 2017 1 commit
  10. 09 Oct, 2017 2 commits
  11. 07 Oct, 2017 2 commits
  12. 04 Oct, 2017 1 commit
  13. 06 Sep, 2017 1 commit
  14. 31 Aug, 2017 1 commit
  15. 30 Aug, 2017 1 commit
  16. 28 Aug, 2017 2 commits
  17. 23 Aug, 2017 1 commit
    • Cache the number of open issues and merge requests · 6ec53f5d
      Yorick Peterse authored
      Every project page displays a navigation menu that in turn displays the
      number of open issues and merge requests. This means that for every
      project page we run two COUNT(*) queries, each taking up roughly 30
      milliseconds on GitLab.com. By caching these numbers and refreshing them
      whenever necessary we can reduce loading times of all these pages by up
      to roughly 60 milliseconds.
      
      The number of open issues does not include confidential issues. This is
      a trade-off to keep the code simple and to ensure refreshing the data
      only needs 2 COUNT(*) queries instead of 3. A downside is that if a
      project only has 5 confidential issues the counter will be set to 0.
      
      Because we now have 3 similar counting service classes the code
      previously used in Projects::ForksCountService has mostly been moved to
      Projects::CountService, which in turn is reused by the various service
      classes.
      
      Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/36622
  18. 13 Aug, 2017 1 commit
  19. 10 Aug, 2017 1 commit
  20. 09 Aug, 2017 1 commit
  21. 07 Aug, 2017 1 commit
  22. 02 Aug, 2017 1 commit
  23. 01 Aug, 2017 1 commit
  24. 27 Jul, 2017 1 commit
  25. 24 Jul, 2017 1 commit
  26. 07 Jul, 2017 1 commit
    • Speed up `all_commit_shas` for new merge requests · 4c0864fd
      Sean McGivern authored
      For merge requests created after 9.4, we have a `merge_request_diff_commits`
      table we can get all the SHAs from very quickly. We just need to exclude these
      when we load from the legacy format, by ignoring diffs with no serialised
      commits.
      
      Once these have been migrated in the background, every MR will see this
      improvement.
  27. 06 Jul, 2017 2 commits
    • Add table for merge request commits · aff5c9f3
      Sean McGivern authored
      This is an ID-less table with just three columns: an association to the merge
      request diff the commit belongs to, the relative order of the commit within the
      merge request diff, and the commit SHA itself.
      
      Previously we stored much more information about the commits, so that we could
      display them even when they were deleted from the repo. Since 8.0, we ensure
      that those commits are kept around for as long as the target repo itself is, so
      we don't need to duplicate that data in the database.
    • Add many foreign keys to the projects table · c63e3221
      Yorick Peterse authored
      This removes the need for relying on Rails' "dependent" option for data
      removal, which is _incredibly_ slow (even when using :delete_all) when
      deleting large amounts of data. This also ensures data consistency is
      enforced on DB level and not on application level (something Rails is
      really bad at).
      
      This commit also includes various migrations to add foreign keys to
      tables that eventually point to "projects" to ensure no rows get
      orphaned upon removing a project.
  28. 26 Jun, 2017 1 commit
  29. 21 Jun, 2017 1 commit
  30. 20 Jun, 2017 1 commit
  31. 15 Jun, 2017 1 commit
  32. 14 Jun, 2017 1 commit
  33. 31 May, 2017 1 commit
  34. 29 May, 2017 1 commit
  35. 23 May, 2017 1 commit