- 28 Jul, 2017 1 commit
-
-
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.
-
- 24 Jul, 2017 1 commit
-
-
Jarka Kadlecova authored
-
- 14 Jul, 2017 1 commit
-
-
Douwe Maan authored
-
- 07 Jul, 2017 3 commits
-
-
Stan Hu authored
Identified via `ENABLE_BULLET=1 bundle exec rspec spec/requests/api/merge_requests_spec.rb:34` Improves speed of #34159
-
James Lopez authored
-
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.
-
- 06 Jul, 2017 4 commits
-
-
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.
-
Yorick Peterse authored
This cop has been renamed to ActiveRecordSerialize to match the way "ActiveRecord" is usually written.
-
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).
-
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.
-
- 26 Jun, 2017 1 commit
-
-
Adam Niedzielski authored
Closes #34052
-
- 21 Jun, 2017 1 commit
-
-
Grzegorz Bizon authored
-
- 20 Jun, 2017 1 commit
-
-
Toon Claes authored
To make it simpler to assign users to an Issuable, make MergeRequest support the attribute `assignee_ids`.
-
- 16 Jun, 2017 1 commit
-
-
Felipe Artur authored
-
- 15 Jun, 2017 1 commit
-
-
Eric Eastwood authored
Fix https://gitlab.com/gitlab-org/gitlab-ce/issues/27070 Deprecate "chat commands" in favor of "slash commands" We looked for things like: - `slash commmand` - `slash_command` - `slash-command` - `SlashCommand`
-
- 31 May, 2017 2 commits
-
-
Douwe Maan authored
-
Yorick Peterse authored
This Cop blacklists the use of ActiveRecord's "serialize" method, except for cases where we already use this.
-
- 29 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 23 May, 2017 2 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
- 18 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 12 May, 2017 2 commits
-
-
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.
-
Valery Sizov authored
-
- 09 May, 2017 1 commit
-
-
Fatih Acet authored
-
- 08 May, 2017 1 commit
-
-
Felipe Artur authored
-
- 04 May, 2017 1 commit
-
-
Valery Sizov authored
-
- 03 May, 2017 1 commit
-
-
Douwe Maan authored
-
- 26 Apr, 2017 1 commit
-
-
mhasbini authored
-
- 25 Apr, 2017 1 commit
-
-
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.
-
- 10 Apr, 2017 1 commit
-
-
Robert Speicher authored
-
- 08 Apr, 2017 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 05 Apr, 2017 3 commits
-
-
Douwe Maan authored
-
Douwe Maan authored
-
Douwe Maan authored
-
- 03 Apr, 2017 2 commits
-
-
Douglas Barbosa Alexandre authored
-
James Edwards-Jones authored
-
- 22 Mar, 2017 1 commit
-
-
mhasbini authored
-
- 21 Mar, 2017 1 commit
-
-
Sean McGivern authored
This reverts merge request !10076
-