Mercurial > kallithea
view docs/usage/locking.rst @ 5256:c5ff0bfefdf8
log_in_user: extract user session setup from LoginController
The next changeset will need to set up a user login session outside
LoginController. 'log_in_user' extracted and added as a top-level
function in kallithea.lib.base since the code doesn't need access to
the current controller.
Code refactored to take a User object instead of a username, to allow
callers flexibility in how the user should be looked up.
author | Søren Løvborg <kwi@kwi.dk> |
---|---|
date | Tue, 14 Jul 2015 13:59:59 +0200 |
parents | 8d065db04909 |
children | 5ae8e644aa88 |
line wrap: on
line source
.. _locking: ================== Repository locking ================== Kallithea has a ``repository locking`` feature, disabled by default. When enabled, every initial clone and every pull gives users (with write permission) the exclusive right to do a push. When repository locking is enabled, repositories get a ``locked`` state that can be true or false. The hg/git commands ``hg/git clone``, ``hg/git pull``, and ``hg/git push`` influence this state: - A ``clone`` or ``pull`` action on the repository locks it (``locked=true``) if the user has write/admin permissions on this repository. - Kallithea will remember the user who locked the repository so only this specific user can unlock the repo (``locked=false``) by performing a ``push`` command. - Every other command on a locked repository from this user and every command from any other user will result in an HTTP return code 423 (Locked). Additionally, the HTTP error includes the <user> that locked the repository (e.g., “repository <repo> locked by user <user>”). Each repository can be manually unlocked by an administrator from the repository settings menu.