^kallithea\.db$

^test\.db$

^Kallithea\.egg-info$

^my\.ini$

^fabfile.py

^\.idea$

1f71ef689d2a3c9978cea6591a1f4e9107a5ca83 rhodecode-0.0.1.7.1

cc48c1541c7e2e84114bf92a0f9cd4b8b1341545 0.0

d17e88a1a88a29f6fac948c94498129e405a40d3 0.1

ad0ce803b40cb17fc3988373052943e041030b02 0.2

c6e32714336345403adf76abb6ebf9b8116fcdc7 0.2.1

14f488a5dc4ca6647bc6acf12534fd137e968aa8 0.2.2

    Michael V. DePalatis <mike@depalatis.net> 2015

    Morten Skaaning <mortens@unity3d.com> 2015

    Nick High <nick@silverchip.org> 2015

    Niemand Jedermann <predatorix@web.de> 2015

    Peter Vitt <petervitt@web.de> 2015

    Robert Martinez <ntttq@inboxen.org> 2015

    Ronny Pfannschmidt <opensource@ronnypfannschmidt.de> 2015

    Sam Jaques <sam.jaques@me.com> 2015

    Søren Løvborg <sorenl@unity3d.com> 2015

    Tuux <tuxa@galaxie.eu.org> 2015

    Viktar Palstsiuk <vipals@gmail.com> 2015

    Dominik Ruf <dominikruf@gmail.com> 2012 2014

The development repository is kept very stable and used in production by the

developers -- you can do the same.

Please visit https://docs.kallithea-scm.org/en/latest/installation.html for

more details.

Source code

-----------

The latest sources can be obtained from

https://kallithea-scm.org/repos/kallithea.

   echo "BRAND = 'rhodecode'" > kallithea/brand.py

This location will depend on where you installed Kallithea. If you installed

via::

then you will find this location at

``$VIRTUAL_ENV/lib/python2.7/site-packages/Kallithea-0.1-py2.7.egg/kallithea``.

One-time conversion

~~~~~~~~~~~~~~~~~~~

database, using the database string you can find in your ``production.ini`` (or

``development.ini``) file. For example, if using SQLite::

   cd /path/to/kallithea

   cp /path/to/rhodecode/rhodecode.db kallithea.db

   pip install sqlalchemy-migrate

.. Note::

   If you started out using the branding interoperability approach mentioned

   above, watch out for stray brand.pyc after removing brand.py.

.. _GitHub: http://github.com/

.. _Subversion: http://subversion.tigris.org/

.. _Git: http://git-scm.com/

.. _Celery: http://celeryproject.org/

.. _vcs: http://pypi.python.org/pypi/vcs

.. _Software Freedom Conservancy: http://sfconservancy.org/

#error_email_from = Kallithea Errors <kallithea-noreply@example.com>

#error_email_from = paste_error@example.com

## SMTP server settings

## Only smtp_server is mandatory. All other settings take the specified default

## values.

#smtp_username =

#smtp_password =

#smtp_port = 25

#smtp_use_tls = false

#smtp_use_ssl = false

## SMTP authentication parameters to use (e.g. LOGIN PLAIN CRAM-MD5, etc.).

## options for showing and identifying changesets

show_sha_length = 12

show_revision_number = false

## gist URL alias, used to create nicer urls for gist. This should be an

## url that does rewrites to _admin/gists/<gistid>.

gist_alias_url =

## white list of API enabled controllers. This allows to add list of

## controllers to which access will be enabled by api_key. eg: to enable

## api access to raw_files put `FilesController:raw`, to enable access to patches

## add `ChangesetController:changeset_patch`. This list should be "," separated

issue_pat = (?:\s*#)(\d+)

## server url to the issue, each {id} will be replaced with match

## fetched from the regex and {repo} is replaced with full repository name

## including groups {repo_name} is replaced with just name of repo

## prefix to add to link to indicate it's an url

## #314 will be replaced by <issue_prefix><id>

issue_prefix = #

## issue_pat, issue_server_link, issue_prefix can have suffixes to specify

## multiple patterns, to other issues server, wiki or others

## below an example how to create a wiki pattern

#issue_pat_wiki = (?:wiki-)(.+)

#issue_prefix_wiki = WIKI-

## instance-id prefix

## a prefix key for this instance used for cache invalidation when running

## multiple instances of kallithea, make sure it's globally unique for

## all running kallithea instances. Leave empty if you don't use it

        "method": "<method_name>",

        "args": {"<arg_key>": "<arg_val>"}

    }

For example, to pull to a local "CPython" mirror using curl::

        --data-binary '{"id":1,"api_key":"xe7cdb2v278e4evbdf5vs04v832v0efvcbcve4a3","method":"pull","args":{"repo":"CPython"}}'

In general, provide

 - *id*, a value of any type, can be used to match the response with the request that it is replying to.

 - *api_key*, for authentication and permission validation.

 - *method*, the name of the method to call -- a list of available methods can be found below.

Kallithea comes with a ``kallithea-api`` command line tool, providing a convenient

way to call the JSON-RPC API.

For example, to call ``get_repo``::

Oops, looks like we forgot to add an argument. Let's try again, now

providing the ``repoid`` as a parameter::

To avoid specifying ``apihost`` and ``apikey`` every time, run::

so you don't have to specify them every time.

API methods

+++++++++++

To get started with development::

        hg clone https://kallithea-scm.org/repos/kallithea

        cd kallithea

        virtualenv ../kallithea-venv

        source ../kallithea-venv/bin/activate

        paster make-config Kallithea my.ini

        paster setup-db my.ini --user=user --email=user@example.com --password=password --repos=/tmp

        paster serve my.ini --reload &

        firefox http://127.0.0.1:5000/

You can also start out by forking https://bitbucket.org/conservancy/kallithea

   overview

   installation

   installation_win

   installation_win_old

   installation_iis

   setup

**Usage**

.. toctree::

   :maxdepth: 1

repository, follow the instructions below::

        hg clone https://kallithea-scm.org/repos/kallithea -u stable

        cd kallithea

        virtualenv ../kallithea-venv

        source ../kallithea-venv/bin/activate

You can now proceed to :ref:`setup`.

To upgrade, simply update the repository with ``hg pull -u`` and restart the

server.

- Assuming you have installed virtualenv_, create a new virtual environment

  for example, in `/srv/kallithea/venv`, using the virtualenv command::

    virtualenv /srv/kallithea/venv

    source /srv/kallithea/venv/bin/activate

.. note:: You can't use UNIX ``sudo`` to source the ``virtualenv`` script; it

   will "activate" a shell that terminates immediately. It is also perfectly

   acceptable (and desirable) to create a virtualenv as a normal user.

- Make a folder for Kallithea data files, and configuration somewhere on the

  filesystem. For example::

    mkdir /srv/kallithea

- Go into the created directory and run this command to install Kallithea::

    pip install kallithea

  Alternatively, download a .tar.gz from http://pypi.python.org/pypi/Kallithea,

  extract it and run::

- This will install Kallithea together with pylons_ and all other required

  python libraries into the activated virtualenv.

You can now proceed to :ref:`setup`.

This will generate a ``dispatch.py`` file in the current directory that contains

the necessary components to finalize an installation into IIS. Once this file

has been generated, it is necessary to run the following command due to the way

that ISAPI-WSGI is made::

This accomplishes two things: generating an ISAPI compliant DLL file,

``_dispatch.dll``, and installing a script map handler into IIS for the

``--root`` specified above pointing to ``_dispatch.dll``.

The ISAPI handler is registered to all file extensions, so it will automatically

is great at finding issues until they exist inside Kallithea, at which point the

ISAPI-WSGI wrapper above uses ``win32traceutil``, which is part of ``pywin32``.

In order to dump output from WSGI using ``win32traceutil`` it is sufficient to

type the following in a console window::

and any exceptions occurring in the WSGI layer and below (i.e. in the Kallithea

application itself) that are uncaught, will be printed here complete with stack

traces, making it a lot easier to identify issues.

If you installed Python 2.7.9+, you already have it (as long as you ran the installer with admin privileges or disabled UAC).

If it was not installed or if you are using Python>=2.6,<2.7.9:

- Go to https://bootstrap.pypa.io

- Right-click on get-pip.py and choose Saves as...

.. note::

   See http://stackoverflow.com/questions/4750806/how-to-install-pip-on-windows

   for details and alternative methods.

  You can also install the dependencies using already compiled Windows binaries packages. A good source of compiled Python packages is http://www.lfd.uci.edu/~gohlke/pythonlibs/. However, not all of the necessary packages for Kallithea are on this site and some are hard to find, so we will stick with using the compiler.

In a command prompt type (adapting paths if necessary)::

  cd C:\Kallithea\Env\Scripts

  activate

The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar

(depending of your folder structure). Then type::

  pip install kallithea

https://raw.github.com/pypa/virtualenv/master/virtualenv.py)

Create a virtual Python environment in C:\\Kallithea\\Env (or similar). To

do so, open a CMD (Python Path should be included in Step3), navigate

where you downloaded "virtualenv.py", and write::

(--no-site-packages is now the default behaviour of virtualenv, no need

to include it)

Step 7 -- Install Kallithea

---------------------------

%comspec% /k ""C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcvarsall.bat"" amd64

In that CMD (loaded with VS2008 PATHs) type::

  cd C:\Kallithea\Env\Scripts (or similar)

  activate

The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar

(depending of your folder structure). Then type::

 pip install kallithea

and password for the initial admin account which ``setup-db`` sets

up for you.

The ``setup-db`` values can also be given on the command line.

Example::

The ``setup-db`` command will create all needed tables and an

admin account. When choosing a root path you can either use a new

empty location, or a location which already contains existing

repositories. If you choose a location which contains existing

repositories Kallithea will add all of the repositories at the chosen

          have set up using the Kallithea web interface.

If your main directory (the same as set in Kallithea settings) is for

example set to ``/srv/repos`` and the repository you are using is

named ``kallithea``, then to clone via ssh you should run::

Using other external tools such as mercurial-server_ or using ssh key-based

authentication is fully supported.

.. note:: In an advanced setup, in order for your ssh access to use

          the same permissions as set up via the Kallithea web

and then *Save*, to enable the LDAP plugin and configure its settings.

Here's a typical LDAP setup::

 Connection settings

 Enable LDAP          = checked

 Port                 = 389

 Account              = <account>

 Password             = <password>

 Connection Security  = LDAPS connection

 Certificate Checks   = DEMAND

Kallithea provides a simple integration with issue trackers. It's possible

to define a regular expression that will match an issue ID in commit messages,

and have that replaced with a URL to the issue. To enable this simply

uncomment the following variables in the ini file::

    issue_pat = (?:^#|\s#)(\w+)

    issue_prefix = #

``issue_pat`` is the regular expression describing which strings in

commit messages will be treated as issue references. A match group in

parentheses should be used to specify the actual issue id.

``issue_prefix`` is prepended to the link text.  ``issue_prefix`` doesn't

necessarily need to be ``#``: if you set issue prefix to ``ISSUE-`` this will

generate a URL in the format:

.. code-block:: html

If needed, more than one pattern can be specified by appending a unique suffix to

the variables. For example::

    issue_pat_wiki = (?:wiki-)(.+)

    issue_prefix_wiki = WIKI-

With these settings, wiki pages can be referenced as wiki-some-id, and every

such reference will be transformed into:

.. code-block:: html

Hook management

---------------

Hooks can be managed in similar way to that used in ``.hgrc`` files.

        #server 127.0.0.1:5002;

    }

    ## gist alias

    server {

       listen          443;

       access_log      /var/log/nginx/gist.access.log;

       error_log       /var/log/nginx/gist.error.log;

       ssl on;

       ssl_certificate     gist.your.kallithea.server.crt;

       ssl_certificate_key gist.your.kallithea.server.key;

       ssl_session_timeout 5m;

       ssl_protocols SSLv3 TLSv1;

       ssl_ciphers DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA:AES256-SHA:DES-CBC3-SHA:AES128-SHA:RC4-SHA:RC4-MD5;

       ssl_prefer_server_ciphers on;

    }

    server {

       listen          443;

       access_log      /var/log/nginx/kallithea.access.log;

       error_log       /var/log/nginx/kallithea.error.log;

       ssl on;

       ssl_certificate     your.kallithea.server.crt;

       ssl_certificate_key your.kallithea.server.key;

       include         /etc/nginx/proxy.conf;

       location / {

            try_files $uri @kallithea;

       }

       location @kallithea {

       }

    }

Here's the proxy.conf. It's tuned so it will not timeout on long

pushes or large pushes::

Here is a sample configuration file for Apache using proxy:

.. code-block:: apache

    <VirtualHost *:80>

            <Proxy *>

              # For Apache 2.4 and later:

              Require all granted

              # For Apache 2.2 and earlier, instead use:

Permanent repository URLs

-------------------------

Due to the complicated nature of repository grouping, URLs of repositories

can often change. For example, a repository originally accessible from::

would get a new URL after moving it to test_group::

Such moving of a repository to a group can be an issue for build systems and

other scripts where the repository paths are hardcoded. To mitigate this,

Kallithea provides permanent URLs using the repository ID prefixed with an

underscore. In all Kallithea URLs, for example those for the changelog and the

file view, a repository name can be replaced by this ``_ID`` string. Since IDs

are always the same, moving the repository to a different group will not affect

such URLs.

In the example, the repository could also be accessible as::

The ID of a given repository can be shown from the repository ``Summary`` page,

by selecting the ``Show by ID`` button next to ``Clone URL``.

Email notifications

.. note:: svn -> hg cloning requires the ``hgsubversion`` library to be

   installed.

If you need to clone repositories that are protected via basic authentication,

you can pass the credentials in the URL, e.g.

clone using the given credentials. Please note that the given credentials will

be stored as plaintext inside the database. However, the authentication

information will not be shown in the clone URL on the summary page.

Specific features configurable in the Admin settings