26 Feb, 2014

1 commit

  • The expected behavior during a GitLab backup restore is to overwrite
    existing database data. This works for MySQL because the output of
    mysqldump contains 'DROP TABLE IF EXISTS' statements. pg_dump on the
    other hand assumes that one will restore into an empty database. When
    this is not the case, during the restore with psql some of the data will
    be skipped if existing data is 'in the way'. By first invoking `rake
    db:schema:load` during a Postgres GitLab backup restore, we make sure
    that all important data is correctly restored.
    Jacob Vosmaer
     

18 Feb, 2014

5 commits


17 Feb, 2014

1 commit


13 Feb, 2014

2 commits


12 Feb, 2014

1 commit


11 Feb, 2014

1 commit


04 Feb, 2014

3 commits


03 Feb, 2014

1 commit


31 Jan, 2014

1 commit


28 Jan, 2014

3 commits


27 Jan, 2014

6 commits


25 Jan, 2014

1 commit


24 Jan, 2014

2 commits


23 Jan, 2014

3 commits


22 Jan, 2014

4 commits


21 Jan, 2014

1 commit

  • The previous phrasing lead some people to believe that there is a limit
    on the number of LDAP users that can sign in to a GitLab instance. That
    is not the case; the limit in the check script only applies to the
    diagnostic information result set, so that running `rake gitlab:check`
    does not output thousands of LDAP users.
    Jacob Vosmaer
     

20 Jan, 2014

2 commits


19 Jan, 2014

2 commits