kallithea Files · docs/usage/locking.rst

Files @ 44835b81c956

Branch filter:

Location: kallithea/docs/usage/locking.rst

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

Thomas De Schampheleire

test_admin_notifications: fix index test dependency

The index test only worked because another test had prepared some database
state it relied on.

More specifically, the index test creates a notification
as a newly created user, but that user had not been committed to the
database yet. When running the index test standalone, this causes the error:

IntegrityError: (IntegrityError) NOT NULL constraint failed:
notifications.created_by u'INSERT INTO notifications (subject, body,
created_by, created_on, type) VALUES (?, ?, ?, ?, ?)'
(u'test_notification_1', u'notification_1', None, '2016-03-11
21:15:19.066402', u'message')

By committing the database after the user is created, the problem is solved.

.. _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`` flag.
The hg/git commands ``hg/git clone``, ``hg/git pull``,
and ``hg/git push`` influence this state:

- A ``clone`` or ``pull`` action locks the target repository
  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 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 will mention 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.