1. 07 Aug, 2013 1 commit
  2. 29 Jul, 2013 1 commit
  3. 22 Jul, 2013 1 commit
  4. 25 Jun, 2013 4 commits
  5. 19 Jun, 2013 2 commits
  6. 12 Jun, 2013 1 commit
  7. 31 May, 2013 1 commit
  8. 30 May, 2013 2 commits
  9. 15 May, 2013 1 commit
  10. 09 May, 2013 1 commit
  11. 08 May, 2013 2 commits
  12. 23 Apr, 2013 1 commit
    • antirez's avatar
      Test: fix RDB test checking file permissions. · c4656119
      antirez authored
      When the test is executed using the root account, setting the permission
      to 222 does not work as expected, as root can read files with 222
      permission.
      
      Now we skip the test if root is detected.
      
      This fixes issue #1034 and the duplicated #1040 issue.
      
      Thanks to Jan-Erik Rediger (@badboy on Github) for finding a way to reproduce the issue.
      c4656119
  13. 22 Apr, 2013 1 commit
  14. 04 Apr, 2013 1 commit
  15. 28 Mar, 2013 3 commits
  16. 27 Mar, 2013 3 commits
  17. 25 Mar, 2013 1 commit
  18. 13 Mar, 2013 2 commits
  19. 12 Mar, 2013 1 commit
  20. 12 Feb, 2013 2 commits
  21. 05 Feb, 2013 1 commit
  22. 28 Jan, 2013 4 commits
  23. 23 Jan, 2013 2 commits
  24. 21 Jan, 2013 1 commit
    • antirez's avatar
      UNSUBSCRIBE and PUNSUBSCRIBE: always provide a reply. · 2039f1a3
      antirez authored
      UNSUBSCRIBE and PUNSUBSCRIBE commands are designed to mass-unsubscribe
      the client respectively all the channels and patters if called without
      arguments.
      
      However when these functions are called without arguments, but there are
      no channels or patters we are subscribed to, the old behavior was to
      don't reply at all.
      
      This behavior is broken, as every command should always reply.
      Also it is possible that we are no longer subscribed to a channels but we
      are subscribed to patters or the other way around, and the client should
      be notified with the correct number of subscriptions.
      
      Also it is not pretty that sometimes we did not receive a reply at all
      in a redis-cli session from these commands, blocking redis-cli trying
      to read the reply.
      
      This fixes issue #714.
      2039f1a3