BigW Consortium Gitlab

  1. 28 Jul, 2017 1 commit
    • Merge issuable "reopened" state into "opened" · 6ef87a20
      Yorick Peterse authored
      Having two states that essentially mean the same thing is very much like
      having a boolean "true" and boolean "mostly-true": it's rather silly.
      This commit merges the "reopened" state into the "opened" state while
      taking care of system notes still showing messages along the lines of
      "Alice reopened this issue".
      
      A big benefit from having only two states (opened and closed) is that
      indexing and querying becomes simpler and more performant. For example,
      to get all the opened queries we no longer have to query both states:
      
          SELECT *
          FROM issues
          WHERE project_id = 2
          AND state IN ('opened', 'reopened');
      
      Instead we can query a single state directly, which can be much faster:
      
          SELECT *
          FROM issues
          WHERE project_id = 2
          AND state = 'opened';
      
      Further, only having two states makes indexing easier as we will only
      ever filter (and thus scan an index) using a single value. Partial
      indexes could help but aren't supported on MySQL, complicating the
      development process and not being helpful for MySQL.
  2. 24 Jul, 2017 1 commit
  3. 14 Jul, 2017 1 commit
  4. 07 Jul, 2017 3 commits
    • Remove many N+1 queries with merge requests API · b963d45c
      Stan Hu authored
      Identified via `ENABLE_BULLET=1 bundle exec rspec spec/requests/api/merge_requests_spec.rb:34`
      
      Improves speed of #34159
    • fix spec · 6d28ad84
      James Lopez authored
    • 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.
  5. 06 Jul, 2017 4 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.
    • Rename ActiverecordSerialize cop · e1a3bf30
      Yorick Peterse authored
      This cop has been renamed to ActiveRecordSerialize to match the way
      "ActiveRecord" is usually written.
    • Added Cop to blacklist the use of `dependent:` · 8fbbf41e
      Yorick Peterse authored
      This is allowed for existing instances so we don't end up 76 offenses
      right away, but for new code one should _only_ use this if they _have_
      to remove non database data. Even then it's usually better to do this in
      a service class as this gives you more control over how to remove the
      data (e.g. in bulk).
    • 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.
  6. 26 Jun, 2017 1 commit
  7. 21 Jun, 2017 1 commit
  8. 20 Jun, 2017 1 commit
  9. 16 Jun, 2017 1 commit
  10. 15 Jun, 2017 1 commit
  11. 31 May, 2017 2 commits
  12. 29 May, 2017 1 commit
  13. 23 May, 2017 2 commits
  14. 18 May, 2017 1 commit
  15. 12 May, 2017 2 commits
    • Fix conflict resolution from corrupted upstream · ad2bfeb8
      Sean McGivern authored
      I don't know why this happens exactly, but given an upstream and fork repository
      from a customer, both of which required GC, resolving conflicts would corrupt
      the fork so badly that it couldn't be cloned.
      
      This isn't a perfect fix for that case, because the MR may still need to be
      merged manually, but it does ensure that the repository is at least usable.
      
      My best guess is that when we generate the index for the conflict
      resolution (which we previously did in the target project), we obtain a
      reference to an OID that doesn't exist in the source, even though we already
      fetch the refs from the target into the source.
      
      Explicitly setting the source project as the place to get the merge index from
      seems to prevent repository corruption in this way.
  16. 09 May, 2017 1 commit
  17. 08 May, 2017 1 commit
  18. 04 May, 2017 1 commit
  19. 03 May, 2017 1 commit
  20. 26 Apr, 2017 1 commit
  21. 25 Apr, 2017 1 commit
    • Show correct size when MR diff overflows · a0979c05
      Sean McGivern authored
      The problem is that we often go via a diff object constructed from the diffs
      stored in the DB. Those diffs, by definition, don't overflow, so we don't have
      access to the 'correct' `real_size` - that is stored on the MR diff object
      iself.
  22. 10 Apr, 2017 1 commit
  23. 08 Apr, 2017 3 commits
  24. 05 Apr, 2017 3 commits
  25. 03 Apr, 2017 2 commits
  26. 22 Mar, 2017 1 commit
  27. 21 Mar, 2017 1 commit