kallithea Files · docs/usage/vcs

Files @ 712a32f1026b

Branch filter:

Location: kallithea/docs/usage/vcs_support.rst

712a32f1026b 2.2 KiB text/prs.fallenstein.rst Show Annotation Show as Raw Download as Raw

Thomas De Schampheleire

tests: api: fix intertest dependency on repository locking

In test classes based on unittest, tests are executed in alphabetical order.
In test classes based on pytest, tests are executed in the order they are
specified. This difference revealed a problem in the API tests:

- test_api_lock_repo_lock_optional_locked locks the test repository
- test_api_get_locks_regular_user gets the current locks and expects it to
be empty

With unittest as base class, this worked fine because the 'get_locks' group
of tests are executed before the 'lock_repo' group (alphabetical order).
Using a real pytest-based test class, the order is swapped and the locked
repository from the first test invalidates the preconditions of the second
test.

Fix this specific problem by releasing the lock from
test_api_lock_repo_lock_optional_locked.

This commit does not fix other interdependencies between tests. For example,
test_api_lock_repo_lock_optional_locked expects the existing lock state to
be 'locked' but did not lock the repo itself; instead it expects a previous
test to have locked. In practice, this is
test_api_lock_repo_lock_aquire_optional_userid.
A full solution would make each test fully self contained so that tests can
be executed in random order. The pytest extension pytest-random can help
detecting these problems.

.. _vcs_support:

===============================
Version control systems support
===============================

Kallithea supports Git and Mercurial repositories out-of-the-box.
For Git, you do need the ``git`` command line client installed on the server.

You can always disable Git or Mercurial support by editing the
file ``kallithea/__init__.py`` and commenting out the backend.

.. code-block:: python

   BACKENDS = {
       'hg': 'Mercurial repository',
       #'git': 'Git repository',
   }


Git support
-----------


Web server with chunked encoding
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Large Git pushes require an HTTP server with support for
chunked encoding for POST. The Python web servers waitress_ and
gunicorn_ (Linux only) can be used. By default, Kallithea uses
waitress_ for `paster serve` instead of the built-in `paste` WSGI
server.

The paster server is controlled in the .ini file::

    use = egg:waitress#main

or::

    use = egg:gunicorn#main

Also make sure to comment out the following options::

    threadpool_workers =
    threadpool_max_requests =
    use_threadpool =


Mercurial support
-----------------


Working with Mercurial subrepositories
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This section explains how to use Mercurial subrepositories_ in Kallithea.

Example usage::

    ## init a simple repo
    hg init mainrepo
    cd mainrepo
    echo "file" > file
    hg add file
    hg ci --message "initial file"

    # clone subrepo we want to add from Kallithea
    hg clone http://kallithea.local/subrepo

    ## specify URL to existing repo in Kallithea as subrepository path
    echo "subrepo = http://kallithea.local/subrepo" > .hgsub
    hg add .hgsub
    hg ci --message "added remote subrepo"

In the file list of a clone of ``mainrepo`` you will see a connected
subrepository at the revision it was cloned with. Clicking on the
subrepository link sends you to the proper repository in Kallithea.

Cloning ``mainrepo`` will also clone the attached subrepository.

Next we can edit the subrepository data, and push back to Kallithea. This will
update both repositories.


.. _waitress: http://pypi.python.org/pypi/waitress
.. _gunicorn: http://pypi.python.org/pypi/gunicorn
.. _subrepositories: http://mercurial.aragost.com/kick-start/en/subrepositories/