1. 08 Dec, 2016 1 commit
  2. 06 Dec, 2016 1 commit
  3. 05 Dec, 2016 3 commits
  4. 02 Dec, 2016 1 commit
  5. 01 Dec, 2016 4 commits
  6. 29 Nov, 2016 4 commits
  7. 28 Nov, 2016 4 commits
  8. 25 Nov, 2016 4 commits
    • hhoopes's avatar
      Add keyword arguments to truncated_diff method · 96868feda665
      hhoopes authored
      * Added keyword arguments to truncated_diff_lines method to allow for using highlighting or not (html templates vs. text)
      * Tweaked templates for consistency and format appropriateness
      96868feda665
    • hhoopes's avatar
      Change diff highlight/truncate for reusability · e9586cd688c2
      hhoopes authored
      Previously the `truncated_diff_lines` method for outputting a discussion diff took in already highlighted lines, which meant it wasn't reuseable for truncating ANY lines. In the way it was used, it also meant that for any email truncation, the whole diff was being highlighted before being truncated, meaning wasted time highlighting lines that wouldn't even be used (granted, they were being memoized, so perhaps this wasn't that great of an issue). I refactored truncation away from highlighting, in order to truncate formatted diffs for text templates in email, using `>`s to designate each line, but otherwise retaining the parsing already done to create `diff_lines`.
      
      Additionally, while notes on merge requests or commits had already been tested, there was no existing test for notes on a diff on an MR or commit. Added mailer tests for such, and a unit test for truncating diff lines.
      e9586cd688c2
    • Yorick Peterse's avatar
      Removed data-user-is view code · 452363214b64
      Yorick Peterse authored
      With events no longer being cached this is no longer needed.
      452363214b64
    • Yorick Peterse's avatar
      Refresh project authorizations using a Redis lease · 0e1cd0df889b
      Yorick Peterse authored
      When I proposed using serializable transactions I was hoping we would be
      able to refresh data of individual users concurrently. Unfortunately
      upon closer inspection it was revealed this was not the case. This could
      result in a lot of queries failing due to serialization errors,
      overloading the database in the process (given enough workers trying to
      update the target table).
      
      To work around this we're now using a Redis lease that is cancelled upon
      completion. This ensures we can update the data of different users
      concurrently without overloading the database.
      
      The code will try to obtain the lease until it succeeds, waiting at
      least 1 second between retries. This is necessary as we may otherwise
      end up _not_ updating the data which is not an option.
      0e1cd0df889b
  9. 24 Nov, 2016 2 commits
  10. 23 Nov, 2016 12 commits
  11. 22 Nov, 2016 2 commits
  12. 21 Nov, 2016 2 commits