BigW Consortium Gitlab

  1. 15 Apr, 2016 1 commit
  2. 13 Apr, 2016 1 commit
    • Fix repository cache invalidation issue when project is recreated with an empty repo · 2ce7559d
      Stan Hu authored
      To reproduce:
      
      1. Create a project with some content
      2. Rename the project
      3. Create a new project with the same name.
      4. Boom - 404.
      
      After step 2, the branch and tag counts were not being cleared. This would
      cause `repository.has_visible_content?` to erroneously return `true`
      for the newly-created project.
      
      Closes #13384
  3. 09 Apr, 2016 1 commit
  4. 07 Apr, 2016 1 commit
  5. 04 Apr, 2016 1 commit
  6. 01 Apr, 2016 1 commit
  7. 27 Mar, 2016 1 commit
  8. 25 Mar, 2016 2 commits
  9. 24 Mar, 2016 1 commit
  10. 19 Mar, 2016 1 commit
    • Cache output of Repository#exists? · 68a4c98f
      Yorick Peterse authored
      This caches the output of Repository#exists? in Redis while making sure
      it's flushed properly when creating new repositories, deleting them,
      etc.
      
      For the ProjectWiki tests to work I had to make ProjectWiki#create_repo!
      public as testing private methods in RSpec is a bit of a pain.
  11. 17 Mar, 2016 2 commits
    • Added tests for Repository#build_cache · dd4b7897
      Yorick Peterse authored
    • Cache project avatars stored in Git · cd05d3f7
      Yorick Peterse authored
      The avatar logic has been moved from Project to Repository as this makes
      caching easier. The logic itself in turn has been changed so that the
      logo file names are cached in Redis. This cache is flushed upon pushing
      a commit but _only_ if:
      
      1. The commit was pushed to the default branch
      2. The commit actually changes any of the logo files
      
      If no branch or commit is given the cache is flushed anyway, this
      ensures that calling Repository#expire_cache without any arguments still
      flushes the avatar cache (e.g. this is used when removing a project).
      
      Fixes gitlab-org/gitlab-ce#14363
  12. 16 Mar, 2016 1 commit
  13. 08 Mar, 2016 5 commits
  14. 07 Mar, 2016 2 commits
  15. 02 Mar, 2016 1 commit
  16. 25 Feb, 2016 1 commit
  17. 20 Feb, 2016 1 commit
    • Flush emptiness caches whenever needed · e0cb3212
      Yorick Peterse authored
      This ensures that the emptiness cache (used for Repository#empty? and
      Repository#has_visible_content?) is flushed after comitting changes
      (using the web editor, API or Git) for new repositories. Once a
      repository is no longer empty there's no need to explicitly flush the
      cache for Repository#empty?. The cache for
      Repository#has_visible_content? in turn is already flushed whenever
      needed.
      
      Fixes gitlab-org/gitlab-ce#13387
  18. 19 Feb, 2016 3 commits
  19. 18 Feb, 2016 3 commits
    • Handle raw_repository returning nil in exists? · 5b6d347f
      Yorick Peterse authored
      If path_with_namespace is nil Repository#raw_repository will also return
      nil. Apparently code out there creates a Repository instance without a
      namespace path. Right.
    • Added specs for Repository#exists? · 8a7aad77
      Yorick Peterse authored
    • Only set autocrlf when creating/updating files · c475b171
      Yorick Peterse authored
      Setting the "autocrlf" Git option is an overkill since it's rarely
      actually needed. More importantly, it has quite the impact on
      performance (see gitlab-org/gitlab-ce#13457 for more information).
      
      By setting "autocrlf" when creating or updating files we guarantee the
      option is always set properly when we actually need it _without_
      introducing overhead for requests that have nothing to do with this
      option.
      
      Fixes gitlab-org/gitlab-ce#13457
  20. 17 Feb, 2016 1 commit
  21. 09 Feb, 2016 1 commit
    • Smarter flushing of branch statistics caches · 2ce0d063
      Yorick Peterse authored
      Instead of flushing the behind/ahead counts for all branches upon every
      push we now only flush the cache of branches that actually need to have
      these statistics recalculated. There are now basically 2 scenarios and
      their effects:
      
      1. A user pushes a commit to the default branch, this results in the
         cache being flushed for all branches.
      2. A user pushes to a non default branch, this results in _only_ the
         cache for that branch being flushed.
      
      The existing code (Repository#expire_cache) remains backwards compatible
      with the previous behaviour, the new behaviour is only applied when a
      branch name is passed as an argument. This ensures that when for example
      a project is deleted the cache for all branches is flushed.
  22. 08 Feb, 2016 2 commits
    • Cache various Repository Git operations · 9a99d8e4
      Yorick Peterse authored
      This caches the output of the following methods:
      
      * Repository#empty?
      * Repository#has_visible_content?
      * Repository#root_ref
      
      The cache for Repository#has_visible_content? is flushed whenever a
      commit is pushed to a new branch or an existing branch is removed.
      The cache for Repository#root_ref is only flushed whenever a user
      changes the default branch of a project. The cache for Repository#empty?
      is never explicitly flushed as there's no need for it.
  23. 21 Jan, 2016 1 commit
  24. 10 Dec, 2015 1 commit
  25. 09 Dec, 2015 1 commit
  26. 03 Dec, 2015 2 commits
  27. 02 Nov, 2015 1 commit