kallithea Files · docs/usage/locking.rst

Files @ e87baa8f1c5b

Branch filter:

Location: kallithea/docs/usage/locking.rst

e87baa8f1c5b 1.1 KiB text/prs.fallenstein.rst Show Annotation Show as Raw Download as Raw

Mads Kiilerich

comments: rework/rewrite javascript for inline comment handling

There shouldn't be any functional changes here, but the focus has been on doing
the right thing instead of looking at how it was before.

Incremental cleanup did not seem feasible. I think this is more readable and
maintainable than before ... at least for me.

Existing snippets has been reused when reimplementing. The new implementation
focus on being as simple as possible and well-structured. jQuery and data
attributes are used instead of custom implementations. Some existing functions
have been modified or renamed, others have been removed when they no longer
were needed.

.. _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.