Even though Git is very resilient and tries to prevent data integrity issues, there are times when things go wrong. The following Rake tasks intend to help GitSwarm administrators diagnose problem repositories so they can be fixed.
There are 3 things that are checked to determine integrity.
config.lock
in the repository directory.refs/heads
.It's important to note that the existence of config.lock
or reference locks alone do not necessarily indicate a problem. Lock files are routinely created and removed as Git and GitSwarm perform operations on the repository. They serve to prevent data integrity issues. However, if a Git operation is interrupted these locks may not be cleaned up properly.
The following symptoms may indicate a problem with repository integrity. If users experience these symptoms you may use the rake tasks described below to determine exactly which repositories are causing the trouble.
remote: error: cannot lock ref
This task loops through all repositories on the GitSwarm server and runs the 3 integrity checks described previously.
# package installations
sudo gitswarm-rake gitswarm:repo:check
# source installation
bundle exec rake gitswarm:repo:check RAILS_ENV=production
This task checks all repositories that a specific user has access to. This is important because sometimes you know which user is experiencing trouble but you don't know which project might be the cause.
If the rake task is executed without brackets at the end, you will be prompted to enter a username.
# package installations
sudo gitswarm-rake gitswarm:user:check_repos
sudo gitswarm-rake gitswarm:user:check_repos[<username>]
# source installation
bundle exec rake gitswarm:user:check_repos RAILS_ENV=production
bundle exec rake gitswarm:user:check_repos[<username>] RAILS_ENV=production
Example output: