##      DB CONFIG      ##

#########################

sqlalchemy.url = sqlite:///%(here)s/kallithea.db?timeout=60

#sqlalchemy.url = postgresql://user:pass@localhost/kallithea

#sqlalchemy.url = mysql://user:pass@localhost/kallithea?charset=utf8

sqlalchemy.pool_recycle = 3600

################################

##   ALEMBIC CONFIGURATION    ##

################################

2. **Install Kallithea software.**

    This makes the ``kallithea-cli`` command line tool available.

3. **Create low level configuration file.**

    Use ``kallithea-cli config-create`` to create a ``.ini`` file with database

4. **Populate the database.**

    Use ``kallithea-cli db-create`` with the ``.ini`` file to create the

    database schema and insert the most basic information: the location of the

    repository store and an initial local admin user.

  directory with Python files and everything else that is needed.

  (``pip install kallithea`` from a source tree will do pretty much the same

  but build the Kallithea package itself locally instead of downloading it.)

.. note::

Web server

----------

Kallithea is (primarily) a WSGI_ application that must be run from a web

- Kallithea uses the Gearbox_ tool as command line interface. Gearbox provides

  ``gearbox serve`` as a convenient way to launch a Python WSGI / web server

  from the command line. That is perfect for development and evaluation.

  Actual use in production might have different requirements and need extra

  work to make it manageable as a scalable system service.

- `Apache httpd`_ can serve WSGI applications directly using mod_wsgi_ and a

  simple Python file with the necessary configuration. This is a good option if

  Apache is an option.

- IIS_ can also server WSGI applications directly using isapi-wsgi_.

- A `reverse HTTP proxy <https://en.wikipedia.org/wiki/Reverse_proxy>`_

  can be put in front of another web server which has WSGI support.

  Such a layered setup can be complex but might in some cases be the right

The best option depends on what you are familiar with and the requirements for

performance and stability. Also, keep in mind that Kallithea mainly is serving

dynamically generated pages from a relatively slow Python process. Kallithea is

also often used inside organizations with a limited amount of users and thus no

continuous hammering from the internet.

.. _Python: http://www.python.org/

.. _Gunicorn: http://gunicorn.org/

.. _Waitress: http://waitress.readthedocs.org/en/latest/

.. _Gearbox: http://turbogears.readthedocs.io/en/latest/turbogears/gearbox.html

.. _PyPI: https://pypi.python.org/pypi

.. _Apache httpd: http://httpd.apache.org/

.. _mod_wsgi: https://code.google.com/p/modwsgi/

.. _isapi-wsgi: https://github.com/hexdump42/isapi-wsgi

    kallithea-cli config-create my.ini host=8.8.8.8 "[handler_console]" formatter=color_formatter

Next, you need to create the databases used by Kallithea. It is recommended to

use PostgreSQL or SQLite (default). If you choose a database other than the

default, ensure you properly adjust the database URL in your ``my.ini``

configuration file to use this other database. Kallithea currently supports

the following command::

    kallithea-cli db-create -c my.ini

This will prompt you for a "root" path. This "root" path is the location where

Kallithea will store all of its repositories on the current machine. After

.. note:: the given path for Mercurial_ repositories **must** be write

          accessible for the application. It's very important since

          the Kallithea web interface will work without write access,

          but when trying to do a push it will fail with permission

          denied errors unless it has write access.

    kallithea-cli front-end-build

You are now ready to use Kallithea. To run it simply execute::

    gearbox serve -c my.ini

If using SQLite, simply make a copy of the Kallithea database (``.db``)

file.

If using PostgreSQL, please consult the documentation for the ``pg_dump``

utility.

utility.

Look for ``sqlalchemy.url`` in your configuration file to determine

database type, settings, location, etc. If you were running Kallithea 0.3.x or

older, this was ``sqlalchemy.db1.url``.

--------

SQLite is a good option when having a small load on the system. But due to

locking issues with SQLite, it is not recommended to use it for larger

deployments.

increase. A tool like SQLAlchemyGrate_ can be used for migrating to another

database platform.

Horizontal scaling

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

%endif

%if database_engine == 'mysql':

sqlalchemy.url = mysql://user:pass@localhost/kallithea?charset=utf8

%else:

#sqlalchemy.url = mysql://user:pass@localhost/kallithea?charset=utf8

%endif

sqlalchemy.pool_recycle = 3600

<%text>##</%text>##############################

<%text>##</%text>   ALEMBIC CONFIGURATION    ##

<%text>##</%text>##############################

        als = self.repository.alias

        for k, vals in self._extract_submodules().items():

            #vals = url,rev,type

            loc = vals[0]

            cs = vals[1]

                                          alias=als))

        nodes = dirnodes + filenodes

        for node in nodes:

            self.nodes[node.path] = node

        nodes.sort()

        return nodes

    def _get_bookmarks(self):

        if self._empty:

            return {}

        return OrderedDict(sorted(

            reverse=True,

            key=lambda x: x[0],  # sort by name

        ))

    def _get_all_revisions(self):

        return [ascii_str(self._repo[x].hex()) for x in self._repo.filtered(b'visible').changelog.revs()]

    def name(self):

        """

        Returns name of the node so if its path

        then only last part is returned.

        """

        org = self.path.rstrip('/').rsplit('/', 1)[-1]