DB Reaping Frequency

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Fix Backup Spec

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

fixed typo at the user management help page

Assuming that VERSION != VERSION.reverse is not robust. This will fail
at e.g. version 6.6.6.

Issue Improve Ui

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Postgres fixes

For applications migrated from MySQL to PostreSQL it fixes some issues
Fixes #1060

 Use new gitlab_git gem. It makes CONTRIBUTING.md work

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Fixed attachment identifier displaying underneath note text

remove dead code: broken_diffs

Less strict backup versions

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Previous to this commit, backups were tied to the git revision (SHA1) of
the app at the time the backup:create command was invoked. If the SHA1
at the time of restore was different, the script would refuse to restore
the backup.  This commit loosens this tie so that the backup script only
complains if the value of the Gitlab::VERSION constant is different
between the time of backup and the time of restore.

Pg Force Restore

Enable html_escape for code blocks highlighted in markdown

Fixes https://gitlab.com/gitlab-org/gitlab-ce/issues/94

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Signed-off-by: Dmitriy Zaporozhets <dmitriy.zaporozhets@gmail.com>

Fix backup/restore git hooks bug

Fixed typo in comments of apllication.scss

Updated changelog with my name for #6267

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.

The backup restore code for repositories was assuming that gitlab-shell
is installed in /home/git/gitlab-shell. This commit changes that to use
the configuration setting from gitlab.yml that specifies the path where
gitlab-shell is installed.