kallithea Changeset - 19af3fef3b34

Changeset - 19af3fef3b34

Parent rev.

Child rev.

[Not reviewed]

Merge stable

! ! !

Thomas De Schampheleire - 7 years ago 2019-03-31 21:28:56
thomas.de_schampheleire@nokia.com

merge default to stable for 0.4.0

47 files changed:

.coveragerc

.hgignore

.hgtags

.travis.yml

CONTRIBUTORS

Jenkinsfile

212

LICENSE.md

132

MANIFEST.in

README.rst

dev_requirements.txt

development.ini

127

250

docs/administrator_guide/auth.rst

110

558

docs/administrator_guide/vcs_setup.rst

docs/api/api.rst

335

docs/api/models.rst

docs/changelog.rst

docs/contributing.rst

200

docs/dev/dbmigrations.rst

docs/dev/translation.rst

docs/images/.img

del

docs/index.rst

docs/installation.rst

100

docs/installation_iis.rst

docs/installation_puppet.rst

docs/installation_win.rst

docs/installation_win_old.rst

docs/make.bat

docs/overview.rst

docs/setup.rst

113

344

docs/theme/nature/static/nature.css_t

docs/upgrade.rst

246

docs/usage/customization.rst

docs/usage/debugging.rst

docs/usage/email.rst

docs/usage/general.rst

docs/usage/performance.rst

docs/usage/troubleshooting.rst

docs/usage/vcs_notes.rst

init.d/celeryd-upstart.conf

init.d/kallithea-daemon-arch

init.d/kallithea-daemon-debian

init.d/kallithea-daemon-gentoo

init.d/kallithea-daemon-redhat

init.d/kallithea-upstart.conf

init.d/supervisord.conf

kallithea/__init__.py

kallithea/alembic/env.py

105

Changeset was too big and was cut off... Show full diff anyway

0 comments (0 inline, 0 general)

.coveragerc

➞

Show inline comments

@@ new file 100644 @@
 [run]
 omit =
     # the bin scripts are not part of the Kallithea web app
     kallithea/bin/*
     # we ship with no active extensions
     kallithea/config/rcextensions/*
     # dbmigrate is not a part of the Kallithea web app
     kallithea/lib/dbmigrate/*
     # the tests themselves should not be part of the coverage report
     kallithea/tests/*
     # the scm hooks are not run in the kallithea process
     kallithea/config/post_receive_tmpl.py
     kallithea/config/pre_receive_tmpl.py
 # same omit lines should be present in sections 'run' and 'report'
 [report]
 omit =
     # the bin scripts are not part of the Kallithea web app
     kallithea/bin/*
     # we ship with no active extensions
     kallithea/config/rcextensions/*
     # dbmigrate is not a part of the Kallithea web app
     kallithea/lib/dbmigrate/*
     # the tests themselves should not be part of the coverage report
     kallithea/tests/*
     # the scm hooks are not run in the kallithea process
     kallithea/config/post_receive_tmpl.py
     kallithea/config/pre_receive_tmpl.py
 [paths]
 source =
     kallithea/
     **/workspace/*/kallithea

.hgignore

➞

Show inline comments

@@ @@ -13,19 +13,40 @@ syntax: regexp @@
 ^rcextensions
 ^build
 ^dist/
 ^docs/build/
 ^docs/_build/
 ^data$
 ^kallithea/tests/data$
 ^sql_dumps/
 ^\.settings$
 ^\.project$
 ^\.pydevproject$
 ^\.coverage$
 ^kallithea/front-end/node_modules$
 ^kallithea/front-end/package-lock\.json$
 ^kallithea/front-end/tmp$
 ^kallithea/public/codemirror$
 ^kallithea/public/css/select2-spinner\.gif$
 ^kallithea/public/css/select2\.png$
 ^kallithea/public/css/select2x2\.png$
 ^kallithea/public/css/style\.css$
 ^kallithea/public/css/style\.css\.map$
 ^kallithea/public/js/bootstrap\.js$
 ^kallithea/public/js/dataTables\.bootstrap\.js$
 ^kallithea/public/js/jquery\.atwho\.min\.js$
 ^kallithea/public/js/jquery\.caret\.min\.js$
 ^kallithea/public/js/jquery\.dataTables\.js$
 ^kallithea/public/js/jquery\.flot\.js$
 ^kallithea/public/js/jquery\.flot\.selection\.js$
 ^kallithea/public/js/jquery\.flot\.time\.js$
 ^kallithea/public/js/jquery\.min\.js$
 ^kallithea/public/js/select2\.js$
 ^theme\.less$
 ^kallithea\.db$
 ^test\.db$
 ^Kallithea\.egg-info$
 ^my\.ini$
 ^fabfile.py
 ^\.idea$
 ^\.cache$
 ^\.pytest_cache$
 /__pycache__$

.hgtags

➞

Show inline comments

@@ @@ -66,6 +66,8 @@ c6e32714336345403adf76abb6ebf9b8116fcdc7 @@
 a84d40e9481fcea4dafadee86b03f0dd401527d6 0.3.2
 ea7ea0923618a0c117acebb816a6f0d162bfdb 0.3.3
 cf635c823ea059cc3a1581b82d8672e46b682384 0.3.4
 cca4cc6a0a97f4c4763317184cd41aca4297630 0.3.5
 c9b8f0f17bd34740eb90c69bdc4c80d4b5b31 0.3.6
 a18445b85d407294da0b7f1d8be3bedef5ffdea6 0.3.7
 db761c407685e7b08b800c947890035b0d67025 0.4.0rc1
 f726162fd6c515bd819feb423be73cad01d7d3 0.4.0rc2

.travis.yml

➞

Show inline comments

deleted file

CONTRIBUTORS

➞

Show inline comments

 List of contributors to Kallithea project:
     Andrej Shadura <andrew@shadura.me> 2012 2014-2017 2019
     Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> 2014-2019
     Étienne Gilli <etienne.gilli@gmail.com> 2015-2017 2019
     Mads Kiilerich <mads@kiilerich.com> 2016-2019
     Allan Nordhøy <epost@anotheragency.no> 2017-2019
     Danni Randeris <danniranderis@gmail.com> 2019
     Edmund Wong <ewong@crazy-cat.org> 2019
     Manuel Jacob <me@manueljacob.de> 2019
     Dominik Ruf <dominikruf@gmail.com> 2012 2014-2018
     Michal Čihař <michal@cihar.com> 2014-2015 2018
     Branko Majic <branko@majic.rs> 2015 2018
     Chris Rule <crule@aegistg.com> 2018
     Jesús Sánchez <jsanchezfdz95@gmail.com> 2018
     Patrick Vane <patrick_vane@lowentry.com> 2018
     Pheng Heong Tan <phtan90@gmail.com> 2018
     ssantos <ssantos@web.de> 2018
     Максим Якимчук <xpinovo@gmail.com> 2018
     Марс Ямбар <mjambarmeta@gmail.com> 2018
     Mads Kiilerich <madski@unity3d.com> 2012-2017
     Unity Technologies 2012-2017
     Andrew Shadura <andrew@shadura.me> 2012 2014-2017
     Dominik Ruf <dominikruf@gmail.com> 2012 2014 2016-2017
     Étienne Gilli <etienne.gilli@gmail.com> 2015 2017
     Søren Løvborg <sorenl@unity3d.com> 2015-2017
     Sam Jaques <sam.jaques@me.com> 2015 2017
     Allan Nordhøy <epost@anotheragency.no> 2017
     Asterios Dimitriou <steve@pci.gr> 2016-2017
     Alessandro Molina <alessandro.molina@axant.it> 2017
     Anton Schur <tonich.sh@gmail.com> 2017
     Ching-Chen Mao <mao@lins.fju.edu.tw> 2017
     Eivind Tagseth <eivindt@gmail.com> 2017
     FUJIWARA Katsunori <foozy@lares.dti.ne.jp> 2017
     Holger Schramm <info@schramm.by> 2017
     Karl Goetz <karl@kgoetz.id.au> 2017
     Lars Kruse <devel@sumpfralle.de> 2017
     Marko Semet <markosemet@googlemail.com> 2017
     Viktar Vauchkevich <victorenator@gmail.com> 2017
     Takumi IINO <trot.thunder@gmail.com> 2012-2016
     Søren Løvborg <sorenl@unity3d.com> 2015-2016
     Jan Heylen <heyleke@gmail.com> 2015-2016
     Robert Martinez <ntttq@inboxen.org> 2015-2016
     Robert Rauch <mail@robertrauch.de> 2015-2016
     Angel Ezquerra <angel.ezquerra@gmail.com> 2016
     Anton Shestakov <av6@dwimlabs.net> 2016
     Brandon Jones <bjones14@gmail.com> 2016
     Kateryna Musina <kateryna@unity3d.com> 2016
     Konstantin Veretennicov <kveretennicov@gmail.com> 2016
     Oscar Curero <oscar@naiandei.net> 2016
     Robert James Dennington <tinytimrob@googlemail.com> 2016
     timeless@gmail.com 2016
     YFdyh000 <yfdyh000@gmail.com> 2016
     Aras Pranckevičius <aras@unity3d.com> 2012-2013 2015
     Sean Farley <sean.michael.farley@gmail.com> 2013-2015
     Christian Oyarzun <oyarzun@gmail.com> 2014-2015
     Joseph Rivera <rivera.d.joseph@gmail.com> 2014-2015
     Anatoly Bubenkov <bubenkoff@gmail.com> 2015
     Andrew Bartlett <abartlet@catalyst.net.nz> 2015
@@ @@ -34,30 +57,29 @@ List of contributors to Kallithea projec @@
     Daniel Hobley <danielh@unity3d.com> 2015
     David Avigni <david.avigni@ankapi.com> 2015
     Denis Blanchette <dblanchette@coveo.com> 2015
     duanhongyi <duanhongyi@doopai.com> 2015
     EriCSN Chang <ericsning@gmail.com> 2015
     Grzegorz Krason <grzegorz.krason@gmail.com> 2015
-    Jan Heylen <heyleke@gmail.com> 2015
+    Jiří Suchan <yed@vanyli.net> 2015
     Kazunari Kobayashi <kobanari@nifty.com> 2015
     Kevin Bullock <kbullock@ringworld.org> 2015
     kobanari <kobanari@nifty.com> 2015
     Marc Abramowitz <marc@marc-abramowitz.com> 2015
     Marc Villetard <marc.villetard@gmail.com> 2015
     Matthias Zilk <matthias.zilk@gmail.com> 2015
     Michael Pohl <michael@mipapo.de> 2015
     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
     Robert Rauch <mail@robertrauch.de> 2015
     Ronny Pfannschmidt <opensource@ronnypfannschmidt.de> 2015
     Tuux <tuxa@galaxie.eu.org> 2015
     Viktar Palstsiuk <vipals@gmail.com> 2015
     Ante Ilic <ante@unity3d.com> 2014
     Bradley M. Kuhn <bkuhn@sfconservancy.org> 2014
     Calinou <calinou@opmbx.org> 2014
     Daniel Anderson <daniel@dattrix.com> 2014
     Henrik Stuart <hg@hstuart.dk> 2014
     Ingo von Borstel <kallithea@planetmaker.de> 2014
     Jelmer Vernooĳ <jelmer@samba.org> 2014

Jenkinsfile

➞

Show inline comments

@@ new file 100644 @@
 def createvirtualenv = ''
 def activatevirtualenv = ''
 node {
     properties([[$class: 'BuildDiscarderProperty',
                   strategy: [$class: 'LogRotator',
                               artifactDaysToKeepStr: '',
                               artifactNumToKeepStr: '10',
                               daysToKeepStr: '',
                               numToKeepStr: '']]]);
     if (isUnix()) {
         createvirtualenv = 'rm -r $JENKINS_HOME/venv/$JOB_NAME || true && virtualenv $JENKINS_HOME/venv/$JOB_NAME'
         activatevirtualenv = '. $JENKINS_HOME/venv/$JOB_NAME/bin/activate'
     } else {
         createvirtualenv = 'rmdir /s /q %JENKINS_HOME%\\venv\\%JOB_NAME% || true && virtualenv %JENKINS_HOME%\\venv\\%JOB_NAME%'
         activatevirtualenv = 'call %JENKINS_HOME%\\venv\\%JOB_NAME%\\Scripts\\activate.bat'
+    }
     stage('checkout') {
         checkout scm
         if (isUnix()) {
             sh 'hg --config extensions.purge= purge --all'
         } else {
             bat 'hg --config extensions.purge= purge --all'
+        }
+    }
     stage('virtual env') {
         def virtualenvscript = """$createvirtualenv
             $activatevirtualenv
             python -m pip install --upgrade pip
             pip install --upgrade setuptools
             pip install --upgrade pylint
             pip install --upgrade pytest-cov
             """
         if (isUnix()) {
             virtualenvscript += """
                 pip install --upgrade python-ldap
                 pip install --upgrade python-pam
                 """
             sh virtualenvscript
         } else {
             bat virtualenvscript
+        }
+    }
     stage('setup') {
         def virtualenvscript = """$activatevirtualenv
             pip install --upgrade -e .
             pip install -r dev_requirements.txt
             python setup.py compile_catalog
             """
         if (isUnix()) {
             sh virtualenvscript
         } else {
             bat virtualenvscript
+        }
         stash name: 'kallithea', useDefaultExcludes: false
+    }
     stage('pylint') {
         sh script: """$activatevirtualenv
             pylint -j 0 --disable=C -f parseable kallithea > pylint.out
             """, returnStatus: true
         archiveArtifacts 'pylint.out'
         try {
             step([$class: 'WarningsPublisher', canComputeNew: false, canResolveRelativePaths: false, defaultEncoding: '', excludePattern: '', healthy: '', includePattern: '', messagesPattern: '', parserConfigurations: [[parserName: 'PyLint', pattern: 'pylint.out']], unHealthy: ''])
         } catch (java.lang.IllegalArgumentException exc) {
             echo "You need to install the 'Warnings Plug-in' to display the pylint report."
             currentBuild.result = 'UNSTABLE'
             echo "Caught: ${exc}"
+        }
+    }
+}
 def pytests = [:]
 pytests['sqlite'] = {
     node {
         ws {
             deleteDir()
             unstash name: 'kallithea'
             if (isUnix()) {
                 sh script: """$activatevirtualenv
                     py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_sqlite.xml --cov=kallithea
                     """, returnStatus: true
             } else {
                 bat script: """$activatevirtualenv
                     py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_sqlite.xml --cov=kallithea
                     """, returnStatus: true
+            }
             sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1SQLITE./g" pytest_sqlite.xml'
             archiveArtifacts 'pytest_sqlite.xml'
             junit 'pytest_sqlite.xml'
             writeFile(file: '.coverage.sqlite', text: readFile('.coverage'))
             stash name: 'coverage.sqlite', includes: '.coverage.sqlite'
+        }
+    }
+}
 pytests['de'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 withEnv(['LANG=de_DE.UTF-8',
                     'LANGUAGE=de',
                     'LC_ADDRESS=de_DE.UTF-8',
                     'LC_IDENTIFICATION=de_DE.UTF-8',
                     'LC_MEASUREMENT=de_DE.UTF-8',
                     'LC_MONETARY=de_DE.UTF-8',
                     'LC_NAME=de_DE.UTF-8',
                     'LC_NUMERIC=de_DE.UTF-8',
                     'LC_PAPER=de_DE.UTF-8',
                     'LC_TELEPHONE=de_DE.UTF-8',
                     'LC_TIME=de_DE.UTF-8',
                 ]) {
                     sh script: """$activatevirtualenv
                         py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_de.xml --cov=kallithea
                         """, returnStatus: true
+                }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1DE./g" pytest_de.xml'
                 archiveArtifacts 'pytest_de.xml'
                 junit 'pytest_de.xml'
                 writeFile(file: '.coverage.de', text: readFile('.coverage'))
                 stash name: 'coverage.de', includes: '.coverage.de'
+            }
+        }
+    }
+}
 pytests['mysql'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 sh """$activatevirtualenv
                     pip install --upgrade MySQL-python
                     """
                 withEnv(['TEST_DB=mysql://kallithea:kallithea@jenkins_mysql/kallithea_test?charset=utf8']) {
                     if (isUnix()) {
                         sh script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_mysql.xml --cov=kallithea
                             """, returnStatus: true
                     } else {
                         bat script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_mysql.xml --cov=kallithea
                             """, returnStatus: true
+                    }
+                }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1MYSQL./g" pytest_mysql.xml'
                 archiveArtifacts 'pytest_mysql.xml'
                 junit 'pytest_mysql.xml'
                 writeFile(file: '.coverage.mysql', text: readFile('.coverage'))
                 stash name: 'coverage.mysql', includes: '.coverage.mysql'
+            }
+        }
+    }
+}
 pytests['postgresql'] = {
     node {
         if (isUnix()) {
             ws {
                 deleteDir()
                 unstash name: 'kallithea'
                 sh """$activatevirtualenv
                     pip install --upgrade psycopg2
                     """
                 withEnv(['TEST_DB=postgresql://kallithea:kallithea@jenkins_postgresql/kallithea_test']) {
                     if (isUnix()) {
                         sh script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_postgresql.xml --cov=kallithea
                             """, returnStatus: true
                     } else {
                         bat script: """$activatevirtualenv
                             py.test -p no:sugar --cov-config .coveragerc --junit-xml=pytest_postgresql.xml --cov=kallithea
                             """, returnStatus: true
+                    }
+                }
                 sh 'sed --in-place "s/\\(classname=[\'\\"]\\)/\\1POSTGRES./g" pytest_postgresql.xml'
                 archiveArtifacts 'pytest_postgresql.xml'
                 junit 'pytest_postgresql.xml'
                 writeFile(file: '.coverage.postgresql', text: readFile('.coverage'))
                 stash name: 'coverage.postgresql', includes: '.coverage.postgresql'
+            }
+        }
+    }
+}
 stage('Tests') {
     parallel pytests
     node {
         unstash 'coverage.sqlite'
         unstash 'coverage.de'
         unstash 'coverage.mysql'
         unstash 'coverage.postgresql'
         if (isUnix()) {
             sh script: """$activatevirtualenv
                 coverage combine .coverage.sqlite .coverage.de .coverage.mysql .coverage.postgresql
                 coverage xml
                 """, returnStatus: true
         } else {
             bat script: """$activatevirtualenv
                 coverage combine .coverage.sqlite .coverage.de .coverage.mysql .coverage.postgresql
                 coverage xml
                 """, returnStatus: true
+        }
         try {
             step([$class: 'CoberturaPublisher', autoUpdateHealth: false, autoUpdateStability: false, coberturaReportFile: 'coverage.xml', failNoReports: false, failUnhealthy: false, failUnstable: false, maxNumberOfBuilds: 0, onlyStable: false, zoomCoverageChart: false])
         } catch (java.lang.IllegalArgumentException exc) {
             echo "You need to install the pipeline compatible 'CoberturaPublisher Plug-in' to display the coverage report."
             currentBuild.result = 'UNSTABLE'
             echo "Caught: ${exc}"
+        }
+    }
+}

LICENSE.md

➞

Show inline comments

@@ @@ -19,75 +19,117 @@ Third-Party Code Incorporated in Kallith @@
 ==========================================
 Various third-party code under GPLv3-compatible licenses is included as part
 of Kallithea.
 Alembic
 -------
 Kallithea incorporates an [Alembic](http://alembic.zzzcomputing.com/en/latest/)
 "migration environment" in `kallithea/alembic`, portions of which is:
 Copyright &copy; 2009-2016 by Michael Bayer.
 Alembic is a trademark of Michael Bayer.
 and licensed under the MIT-permissive license, which is
 [included in this distribution](MIT-Permissive-License.txt).
 Bootstrap
 ---------
-Kallithea incorporates parts of the Javascript system called
+Kallithea uses the web framework called
 [Bootstrap](http://getbootstrap.com/), which is:
-Copyright &copy; 2012 Twitter, Inc.
+Copyright &copy; 2011-2016 Twitter, Inc.
 and licensed under
 [the Apache License 2.0](http://www.apache.org/licenses/LICENSE-2.0.html).
 and licensed under the MIT-permissive license, which is
 [included in this distribution](MIT-Permissive-License.txt).
 A copy of the Apache License 2.0 is also included in this distribution in its
 entirety in the file Apache-License-2.0.txt
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 Codemirror
 ----------
-Kallithea incorporates parts of the Javascript system called
+Kallithea uses the Javascript system called
 [Codemirror](http://codemirror.net/), version 4.7.0, which is primarily:
 Copyright &copy; 2013-2014 by Marijn Haverbeke <marijnh@gmail.com>
 and licensed under the MIT-permissive license, which is
 [included in this distribution](MIT-Permissive-License.txt).
 Additional files from upstream Codemirror are copyrighted by various authors
 and licensed under other permissive licenses.  The sub-directories under
 [.../public/codemirror](kallithea/public/codemirror) include the copyright and
 license notice and information as they appeared in Codemirror's upstream
 release.
 and licensed under other permissive licenses.
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 jQuery
 ------
 Kallithea incorporates the Javascript system called
 [jQuery](http://jquery.org/),
 [herein](kallithea/public/js/jquery-1.11.1.min.js), and the Corresponding
 Source can be found in https://github.com/jquery/jquery at tag 1.11.1
 (mirrored at https://kallithea-scm.org/repos/mirror/jquery/files/1.11.1/ ).
 Kallithea uses the Javascript system called
 [jQuery](http://jquery.org/).
 It is Copyright 2013 jQuery Foundation and other contributors http://jquery.com/ and is under an
 [MIT-permissive license](MIT-Permissive-License.txt).
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 At.js
 -----
 Kallithea uses the Javascript system called
 [At.js](http://ichord.github.com/At.js),
 which can be found together with its Corresponding Source in
 https://github.com/ichord/At.js at tag v1.5.4.
 It is Copyright 2013 chord.luo@gmail.com and is under an
 [MIT-permissive license](MIT-Permissive-License.txt).
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 Mousetrap
 ---------
 Caret.js
 --------
 Kallithea incorporates parts of the Javascript system called
 [Mousetrap](http://craig.is/killing/mice/), which is:
 Kallithea uses the Javascript system called
 [Caret.js](http://ichord.github.com/Caret.js/),
 which can be found together with its Corresponding Source in
 https://github.com/ichord/Caret.js at tag v0.3.1.
 It is Copyright 2013 chord.luo@gmail.com and is under an
 [MIT-permissive license](MIT-Permissive-License.txt).
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
    Copyright 2013 Craig Campbell
 DataTables
 ----------
 and licensed under
 [the Apache License 2.0](http://www.apache.org/licenses/LICENSE-2.0.html).
 Kallithea uses the Javascript system called
 [DataTables](http://www.datatables.net/).
 A [copy of the Apache License 2.0](Apache-License-2.0.txt) is also included
 in this distribution.
 It is Copyright 2008-2015 SpryMedia Ltd. and is under an
 [MIT-permissive license](MIT-Permissive-License.txt).
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 Mergely
 -------
@@ @@ -100,13 +142,13 @@ tri-license. @@
 Select2
 -------
-Kallithea incorporates parts of the Javascript system called
+Kallithea uses the Javascript system called
 [Select2](http://ivaynberg.github.io/select2/), which is:
 Copyright 2012 Igor Vaynberg (and probably others)
 and is licensed [under the following license](https://github.com/ivaynberg/select2/blob/master/LICENSE):
@@ @@ -119,152 +161,76 @@ and is licensed [under the following lic @@
 A [copy of the Apache License 2.0](Apache-License-2.0.txt) is also included
 in this distribution.
 Kallithea will take the Apache license fork of the dual license, since
 Kallithea is GPLv3'd.
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 Select2-Bootstrap-CSS
 ---------------------
-Kallithea incorporates some CSS from a system called
+Kallithea uses some CSS from a system called
 [Select2-bootstrap-css](https://github.com/t0m/select2-bootstrap-css), which
 is:
 Copyright &copy; 2013 Tom Terrace (and likely others)
 and licensed under the MIT-permissive license, which is
 [included in this distribution](MIT-Permissive-License.txt).
 History.js
 ----------
 Kallithea incorporates some CSS from a system called History.js, which is
 Copyright 2010-2011 Benjamin Arthur Lupton <contact@balupton.com>
 Redistribution and use in source and binary forms, with or without
 modification, are permitted provided that the following conditions are met:
 . Redistributions of source code must retain the above copyright notice,
    this list of conditions and the following disclaimer.
 . Redistributions in binary form must reproduce the above copyright notice,
    this list of conditions and the following disclaimer in the documentation
    and/or other materials provided with the distribution.
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE
 LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
 CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
 SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
 INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
 CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
 ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 POSSIBILITY OF SUCH DAMAGE.
 YUI
 ---
 Kallithea incorporates parts of the Javascript system called
 [YUI 2 — Yahoo! User Interface Library](http://yui.github.io/yui2/docs/yui_2.9.0_full/),
 which is made available under the [BSD License](http://yuilibrary.com/license/):
 Copyright &copy; 2013 Yahoo! Inc. All rights reserved.
 Redistribution and use of this software in source and binary forms, with or
 without modification, are permitted provided that the following conditions are
 met:
 * Redistributions of source code must retain the above copyright notice, this
   list of conditions and the following disclaimer.
 * Redistributions in binary form must reproduce the above copyright notice,
   this list of conditions and the following disclaimer in the documentation
   and/or other materials provided with the distribution.
 * Neither the name of Yahoo! Inc. nor the names of YUI's contributors may be
   used to endorse or promote products derived from this software without
   specific prior written permission of Yahoo! Inc.
 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
 WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
 DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
 ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
 (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
 LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
 ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 Kallithea includes a minified version of YUI 2.9. To build yui.2.9.js:
     git clone https://github.com/yui/builder
     git clone https://github.com/yui/yui2
     cd yui2/
     git checkout hudson-yui2-2800
     ln -sf JumpToPageDropDown.js src/paginator/js/JumpToPageDropdown.js # work around inconsistent casing
     rm -f tmp.js
     for m in yahoo event dom connection animation dragdrop element datasource autocomplete container event-delegate json datatable paginator; do
       rm -f build/\$m/\$m.js
       ( cd src/\$m && ant build deploybuild ) && sed -e 's,@VERSION@,2.9.0,g' -e 's,@BUILD@,2800,g' build/\$m/\$m.js >> tmp.js
     done
     java -jar ../builder/componentbuild/lib/yuicompressor/yuicompressor-2.4.4.jar tmp.js -o yui.2.9.js
 In compliance with GPLv3 the Corresponding Source for this Object Code is made
 available on
 [https://kallithea-scm.org/repos/mirror](https://kallithea-scm.org/repos/mirror).
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 Flot
 ----
 Kallithea incorporates some CSS from a system called
 [Flot](http://code.google.com/p/flot/), which is:
 Kallithea uses some parts of a Javascript system called
 [Flot](http://www.flotcharts.org/), which is:
-Copyright 2006 Google Inc.
+Copyright (c) 2007-2014 IOLA and Ole Laursen
 Licensed under the Apache License, Version 2.0 (the "License");
 you may not use this file except in compliance with the License.
 A [copy of the Apache License 2.0](Apache-License-2.0.txt) is also included
 in this distribution.
 Permission is hereby granted, free of charge, to any person
 obtaining a copy of this software and associated documentation
 files (the "Software"), to deal in the Software without
 restriction, including without limitation the rights to use,
 copy, modify, merge, publish, distribute, sublicense, and/or sell
 copies of the Software, and to permit persons to whom the
 Software is furnished to do so, subject to the following
 conditions:
 Migrate
 -------
 The above copyright notice and this permission notice shall be
 included in all copies or substantial portions of the Software.
 Kallithea incorporates in kallithea/lib/dbmigrate/migrate parts of the Python
 system called [Migrate or sqlalchemy-migrate](https://github.com/stackforge/sqlalchemy-migrate),
 which is:
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
 OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
 HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
 WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
 FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
 OTHER DEALINGS IN THE SOFTWARE.
 Copyright (c) 2009 Evan Rosson, Jan Dittberner, Domen Kožar
 It is not distributed with Kallithea, but will be downloaded
 using the ''kallithea-cli front-end-build'' command.
 and licensed under the MIT-permissive license, which is
 [included in this distribution](MIT-Permissive-License.txt).
 Icon fonts
 ----------
 Kallithea incorporates subsets of both
 [Font Awesome](http://fontawesome.io) and
 [GitHub Octicons](https://octicons.github.com) for icons. Font Awesome is:
-Copyright (c) 2012, Dave Gandy
+Copyright (c) 2016, Dave Gandy
 Octicons is:
 Copyright (c) 2012-2014 GitHub
 These two sets are distributed under [SIL OFL 1.1](http://scripts.sil.org/OFL)

MANIFEST.in

➞

Show inline comments

 include           .coveragerc
 include           Apache-License-2.0.txt
 include           CONTRIBUTORS
 include           COPYING
 include           Jenkinsfile
 include           LICENSE-MERGELY.html
 include           LICENSE.md
 include           MIT-Permissive-License.txt
 include           README.rst
 include           dev_requirements.txt
 include           development.ini
 include           pytest.ini
 include           requirements.txt
 include           tox.ini
 recursive-include docs *
 recursive-include init.d *
 recursive-include kallithea/alembic *
 include           kallithea/bin/ldap_sync.conf
 include           kallithea/bin/template.ini.mako
 include           kallithea/config/deployment.ini_tmpl
 include           kallithea/lib/paster_commands/template.ini.mako
 recursive-include kallithea/front-end *
 recursive-include kallithea/i18n *
 recursive-include kallithea/lib/dbmigrate *.py_tmpl README migrate.cfg
 recursive-include kallithea/public *
 recursive-include kallithea/templates *
 recursive-include kallithea/tests/fixtures *
 recursive-include kallithea/tests/scripts *
 include           kallithea/tests/test.ini
 include           kallithea/tests/models/test_dump_html_mails.ref.html
 include           kallithea/tests/performance/test_vcs.py
 include           kallithea/tests/vcs/aconfig
 recursive-include scripts *

README.rst

➞

Show inline comments

@@ @@ -159,82 +159,20 @@ You can also build the documentation loc @@
 .. note:: You need to have Sphinx_ installed to build the
           documentation. If you don't have Sphinx_ installed you can
           install it via the command: ``pip install sphinx`` .
 Converting from RhodeCode
 -------------------------
 Currently, you have two options for working with an existing RhodeCode
 database:
 - keep the database unconverted (intended for testing and evaluation)
 - convert the database in a one-time step
 Maintaining interoperability
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 Interoperability with RhodeCode 2.2.X installations is provided so you don't
 have to immediately commit to switching to Kallithea. This option will most
 likely go away once the two projects have diverged significantly.
 To run Kallithea on a RhodeCode database, run::
    echo "BRAND = 'rhodecode'" > kallithea/brand.py
 This location will depend on where you installed Kallithea. If you installed
 via::
    python2 setup.py install
 then you will find this location at
 ``$VIRTUAL_ENV/lib/python2.7/site-packages/Kallithea-0.1-py2.7.egg/kallithea``.
 One-time conversion
 ~~~~~~~~~~~~~~~~~~~
 Migrating from RhodeCode
 ------------------------
 Alternatively, if you would like to convert the database for good, you can use
 a helper script provided by Kallithea. This script will operate directly on the
 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
    python2 kallithea/bin/rebranddb.py sqlite:///kallithea.db
 .. Note::
    If you started out using the branding interoperability approach mentioned
    above, watch out for stray brand.pyc after removing brand.py.
 Git hooks
 ~~~~~~~~~
 After switching to Kallithea, it will be necessary to update the Git_ hooks in
 your repositories. If not, the Git_ hooks from RhodeCode will still be called,
 which will cause ``git push`` to fail every time.
 If you do not have any custom Git_ hooks deployed, perform the following steps
 (this may take some time depending on the number and size of repositories you
 have):
 . Log-in as an administrator.
 . Open page *Admin > Settings > Remap and Rescan*.
 . Turn on the option **Install Git Hooks**.
 . Turn on the option **Overwrite existing Git hooks**.
 . Click on the button **Rescan Repositories**.
 If you do have custom hooks, you will need to merge those changes manually. In
 order to get sample hooks from Kallithea, the easiest way is to create a new Git_
 repository, and have a look at the hooks deployed there.
 Kallithea 0.3.2 and earlier supports migrating from an existing RhodeCode
 installation. To migrate, install Kallithea 0.3.2 and follow the
 instructions in the 0.3.2 README to perform a one-time conversion of the
 database from RhodeCode to Kallithea, before upgrading to this version
 of Kallithea.
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _Python: http://www.python.org/
 .. _Sphinx: http://sphinx.pocoo.org/
 .. _Mercurial: http://mercurial.selenic.com/

dev_requirements.txt

➞

Show inline comments

@@ new file 100644 @@
 pytest >= 3.3.0, < 3.8
 pytest-runner < 4.3
 pytest-sugar >= 0.7.0, < 0.10
 pytest-benchmark < 3.2
 pytest-localserver < 0.5
 mock < 2.1
 Sphinx < 1.8
 WebTest < 2.1

development.ini

➞

Show inline comments

 ################################################################################
 ################################################################################
 # Kallithea - Development config:                                              #
 # listening on *:5000                                                          #
 # sqlite and kallithea.db                                                      #
 # initial_repo_scan = true                                                     #
 # set debug = true                                                             #
 # verbose and colorful logging                                                 #
 # Kallithea - config file generated with kallithea-config                      #
 #                                                                              #
 # The %(here)s variable will be replaced with the parent directory of this file#
 ################################################################################
 ################################################################################
 [DEFAULT]
 debug = true
 pdebug = false
 ################################################################################
 ## Email settings                                                             ##
 ##                                                                            ##
 ## Refer to the documentation ("Email settings") for more details.            ##
 ##                                                                            ##
@@ @@ -36,174 +29,88 @@ pdebug = false @@
 ## Default:
 #email_prefix =
 ## Example:
 #email_prefix = [Kallithea]
 ## Recipients for error emails and fallback recipients of application mails.
-## Multiple addresses can be specified, space-separated.
+## Multiple addresses can be specified, comma-separated.
 ## Only addresses are allowed, do not add any name part.
 ## Default:
 #email_to =
 ## Examples:
 #email_to = admin@example.com
 #email_to = admin@example.com another_admin@example.com
 #email_to = admin@example.com,another_admin@example.com
 email_to =
 ## 'From' header for error emails. You can optionally add a name.
 ## Default:
 #error_email_from = pylons@yourapp.com
 ## Default: (none)
 ## Examples:
 #error_email_from = Kallithea Errors <kallithea-noreply@example.com>
 #error_email_from = paste_error@example.com
 #error_email_from = kallithea_errors@example.com
 error_email_from =
 ## SMTP server settings
 ## Only smtp_server is mandatory. All other settings take the specified default
 ## values.
 #smtp_server = smtp.example.com
 ## If specifying credentials, make sure to use secure connections.
 ## Default: Send unencrypted unauthenticated mails to the specified smtp_server.
 ## For "SSL", use smtp_use_ssl = true and smtp_port = 465.
 ## For "STARTTLS", use smtp_use_tls = true and smtp_port = 587.
 smtp_server =
 #smtp_username =
 #smtp_password =
 #smtp_port = 25
 #smtp_use_tls = false
 smtp_port =
 #smtp_use_ssl = false
 ## SMTP authentication parameters to use (e.g. LOGIN PLAIN CRAM-MD5, etc.).
 ## If empty, use any of the authentication parameters supported by the server.
 #smtp_auth =
 #smtp_use_tls = false
 ## Entry point for 'gearbox serve'
 [server:main]
 ## PASTE ##
 #use = egg:Paste#http
 ## nr of worker threads to spawn
 #threadpool_workers = 1
 ## max request before thread respawn
 #threadpool_max_requests = 100
 ## option to use threads of process
 #use_threadpool = true
 #host = 127.0.0.1
 host = 0.0.0.0
 port = 5000
 ## WAITRESS ##
 use = egg:waitress#main
 ## number of worker threads
 threads = 1
 ## MAX BODY SIZE 100GB
 max_request_body_size = 107374182400
 ## use poll instead of select, fixes fd limits, may not work on old
 ## windows systems.
 #asyncore_use_poll = True
 ## GUNICORN ##
 #use = egg:gunicorn#main
 ## number of process workers. You must set `instance_id = *` when this option
 ## is set to more than one worker
 #workers = 1
 ## process name
 #proc_name = kallithea
 ## type of worker class, one of sync, eventlet, gevent, tornado
 ## recommended for bigger setup is using of of other than sync one
 #worker_class = sync
 #max_requests = 1000
 ## ammount of time a worker can handle request before it gets killed and
 ## restarted
 #timeout = 3600
 ## UWSGI ##
 ## run with uwsgi --ini-paste-logged <inifile.ini>
 #[uwsgi]
 #socket = /tmp/uwsgi.sock
 #master = true
 #http = 127.0.0.1:5000
 ## set as deamon and redirect all output to file
 #daemonize = ./uwsgi_kallithea.log
 ## master process PID
 #pidfile = ./uwsgi_kallithea.pid
 ## stats server with workers statistics, use uwsgitop
 ## for monitoring, `uwsgitop 127.0.0.1:1717`
 #stats = 127.0.0.1:1717
 #memory-report = true
 ## log 5XX errors
 #log-5xx = true
 ## Set the socket listen queue size.
 #listen = 256
 ## Gracefully Reload workers after the specified amount of managed requests
 ## (avoid memory leaks).
 #max-requests = 1000
 ## enable large buffers
 #buffer-size = 65535
 ## socket and http timeouts ##
 #http-timeout = 3600
 #socket-timeout = 3600
 ## Log requests slower than the specified number of milliseconds.
 #log-slow = 10
 ## Exit if no app can be loaded.
 #need-app = true
 ## Set lazy mode (load apps in workers instead of master).
 #lazy = true
 ## scaling ##
 ## set cheaper algorithm to use, if not set default will be used
 #cheaper-algo = spare
 ## minimum number of workers to keep at all times
 #cheaper = 1
 ## number of workers to spawn at startup
 #cheaper-initial = 1
 ## maximum number of workers that can be spawned
 #workers = 4
 ## how many workers should be spawned at a time
 #cheaper-step = 1
 ## COMMON ##
 host = 0.0.0.0
 port = 5000
 ## middleware for hosting the WSGI application under a URL prefix
 #[filter:proxy-prefix]
 #use = egg:PasteDeploy#prefix
 #prefix = /<your-prefix>
 [app:main]
 use = egg:kallithea
 ## enable proxy prefix middleware
 #filter-with = proxy-prefix
 full_stack = true
 static_files = true
 ## Available Languages:
 ## cs de fr hu ja nl_BE pl pt_BR ru sk zh_CN zh_TW
 lang =
 ## Internationalization (see setup documentation for details)
 ## By default, the language requested by the browser is used if available.
 #i18n.enable = false
 ## Fallback language, empty for English (valid values are the names of subdirectories in kallithea/i18n):
 i18n.lang =
 cache_dir = %(here)s/data
 index_dir = %(here)s/data/index
 ## perform a full repository scan on each server start, this should be
 ## set to false after first startup, to allow faster server restarts.
 #initial_repo_scan = false
 initial_repo_scan = true
 ## uncomment and set this path to use archive download cache
 archive_cache_dir = %(here)s/tarballcache
 ## change this to unique ID for security
 #app_instance_uuid = VERY-SECRET
 app_instance_uuid = development-not-secret
 ## cut off limit for large diffs (size in bytes)
 cut_off_limit = 256000
 ## use cache version of scm repo everywhere
 vcs_full_cache = true
 ## force https in Kallithea, fixes https redirects, assumes it's always https
 force_https = false
 ## use Strict-Transport-Security headers
 use_htsts = false
@@ @@ -223,12 +130,17 @@ rss_items_per_page = 10 @@
 rss_include_diff = false
 ## options for showing and identifying changesets
 show_sha_length = 12
 show_revision_number = false
 ## Canonical URL to use when creating full URLs in UI and texts.
 ## Useful when the site is available under different names or protocols.
 ## Defaults to what is provided in the WSGI environment.
 #canonical_url = https://kallithea.example.com/repos
 ## gist URL alias, used to create nicer urls for gist. This should be an
 ## url that does rewrites to _admin/gists/<gistid>.
 ## example: http://gist.example.com/{gistid}. Empty means use the internal
 ## Kallithea url, ie. http[s]://kallithea.example.com/_admin/gists/<gistid>
 gist_alias_url =
@@ @@ -242,52 +154,59 @@ api_access_controllers_whitelist = @@
 #    ChangesetController:changeset_patch,
 #    ChangesetController:changeset_raw,
 #    FilesController:raw,
 #    FilesController:archivefile
 ## default encoding used to convert from and to unicode
 ## can be also a comma seperated list of encoding in case of mixed encodings
 default_encoding = utf8
 ## can be also a comma separated list of encoding in case of mixed encodings
 default_encoding = utf-8
 ## Set Mercurial encoding, similar to setting HGENCODING before launching Kallithea
 hgencoding = utf-8
 ## issue tracker for Kallithea (leave blank to disable, absent for default)
 #bugtracker = https://bitbucket.org/conservancy/kallithea/issues
 ## issue tracking mapping for commits messages
 ## comment out issue_pat, issue_server, issue_prefix to enable
 ## issue tracking mapping for commit messages, comments, PR descriptions, ...
 ## Refer to the documentation ("Integration with issue trackers") for more details.
 ## pattern to get the issues from commit messages
 ## default one used here is #<numbers> with a regex passive group for `#`
 ## {id} will be all groups matched from this pattern
 ## regular expression to match issue references
 ## This pattern may/should contain parenthesized groups, that can
 ## be referred to in issue_server_link or issue_sub using Python backreferences
 ## (e.g. \1, \2, ...). You can also create named groups with '(?P<groupname>)'.
 ## To require mandatory whitespace before the issue pattern, use:
 ## (?:^|(?<=\s)) before the actual pattern, and for mandatory whitespace
 ## behind the issue pattern, use (?:$|(?=\s)) after the actual pattern.
-issue_pat = (?:\s*#)(\d+)
 issue_pat = #(\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
 issue_server_link = https://issues.example.com/{repo}/issue/{id}
 ## server url to the issue
 ## This pattern may/should contain backreferences to parenthesized groups in issue_pat.
 ## A backreference can be \1, \2, ... or \g<groupname> if you specified a named group
 ## called 'groupname' in issue_pat.
 ## The special token {repo} is replaced with the full repository name
 ## including repository groups, while {repo_name} is replaced with just
 ## the name of the repository.
 ## prefix to add to link to indicate it's an url
 ## #314 will be replaced by <issue_prefix><id>
 issue_server_link = https://issues.example.com/{repo}/issue/\1
 issue_prefix = #
 ## substitution pattern to use as the link text
 ## If issue_sub is empty, the text matched by issue_pat is retained verbatim
 ## for the link text. Otherwise, the link text is that of issue_sub, with any
 ## backreferences to groups in issue_pat replaced.
 ## issue_pat, issue_server_link, issue_prefix can have suffixes to specify
 issue_sub =
 ## issue_pat, issue_server_link and issue_sub can have suffixes to specify
 ## multiple patterns, to other issues server, wiki or others
 ## below an example how to create a wiki pattern
 # wiki-some-id -> https://wiki.example.com/some-id
 #issue_pat_wiki = (?:wiki-)(.+)
 #issue_server_link_wiki = https://wiki.example.com/{id}
 #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
 instance_id =
 #issue_pat_wiki = wiki-(\S+)
 #issue_server_link_wiki = https://wiki.example.com/\1
 #issue_sub_wiki = WIKI-\1
 ## alternative return HTTP header for failed authentication. Default HTTP
 ## response is 401 HTTPUnauthorized. Currently Mercurial clients have trouble with
 ## handling that. Set this variable to 403 to return HTTPForbidden
 auth_ret_code =
@@ @@ -298,38 +217,46 @@ lock_ret_code = 423 @@
 ## allows to change the repository location in settings page
 allow_repo_location_change = True
 ## allows to setup custom hooks in settings page
 allow_custom_hooks_settings = True
 ## extra extensions for indexing, space separated and without the leading '.'.
 # index.extensions =
 #    gemfile
 #    lock
 ## extra filenames for indexing, space separated
 # index.filenames =
 #    .dockerignore
 #    .editorconfig
 #    INSTALL
 #    CHANGELOG
 ####################################
 ###        CELERY CONFIG        ####
 ####################################
 use_celery = false
 broker.host = localhost
 broker.vhost = rabbitmqhost
 broker.port = 5672
 broker.user = rabbitmq
 broker.password = qweqwe
 ## Example: connect to the virtual host 'rabbitmqhost' on localhost as rabbitmq:
 broker.url = amqp://rabbitmq:qewqew@localhost:5672/rabbitmqhost
 celery.imports = kallithea.lib.celerylib.tasks
+celery.accept.content = pickle
 celery.result.backend = amqp
 celery.result.dburi = amqp://
 celery.result.serialier = json
 #celery.send.task.error.emails = true
 #celery.amqp.task.result.expires = 18000
 celeryd.concurrency = 2
 #celeryd.log.file = celeryd.log
 celeryd.log.level = DEBUG
 celeryd.max.tasks.per.child = 1
 ## tasks will never be sent to the queue, but executed locally instead.
+## If true, tasks will never be sent to the queue, but executed locally instead.
 celery.always.eager = false
 ####################################
 ###         BEAKER CACHE        ####
 ####################################
@@ @@ -360,12 +287,13 @@ beaker.session.key = kallithea @@
 ## Sessions should always only be accessible by the browser, not directly by JavaScript.
 beaker.session.httponly = true
 ## Session lifetime. 2592000 seconds is 30 days.
 beaker.session.timeout = 2592000
 ## Server secret used with HMAC to ensure integrity of cookies.
 #beaker.session.secret = VERY-SECRET
 beaker.session.secret = development-not-secret
 ## Further, encrypt the data with AES.
 #beaker.session.encrypt_key = <key_for_encryption>
 #beaker.session.validate_key = <validation_key>
 ## Type of storage used for the session, current types are
@@ @@ -379,96 +307,19 @@ beaker.session.secret = development-not- @@
 ## Database storage of session data.
 #beaker.session.type = ext:database
 #beaker.session.sa.url = postgresql://postgres:qwe@localhost/kallithea
 #beaker.session.table_name = db_session
 ############################
 ## ERROR HANDLING SYSTEMS ##
 ############################
 ####################
 ### [appenlight] ###
 ####################
 ## AppEnlight is tailored to work with Kallithea, see
 ## http://appenlight.com for details how to obtain an account
 ## you must install python package `appenlight_client` to make it work
 ## appenlight enabled
 appenlight = false
 appenlight.server_url = https://api.appenlight.com
 appenlight.api_key = YOUR_API_KEY
 ## TWEAK AMOUNT OF INFO SENT HERE
 ## enables 404 error logging (default False)
 appenlight.report_404 = false
 ## time in seconds after request is considered being slow (default 1)
 appenlight.slow_request_time = 1
 ## record slow requests in application
 ## (needs to be enabled for slow datastore recording and time tracking)
 appenlight.slow_requests = true
 ## enable hooking to application loggers
 #appenlight.logging = true
 ## minimum log level for log capture
 #appenlight.logging.level = WARNING
 ## send logs only from erroneous/slow requests
 ## (saves API quota for intensive logging)
 appenlight.logging_on_error = false
 ## list of additonal keywords that should be grabbed from environ object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always send following info:
 ## 'REMOTE_USER', 'REMOTE_ADDR', 'SERVER_NAME', 'CONTENT_TYPE' + all keys that
 ## start with HTTP* this list be extended with additional keywords here
 appenlight.environ_keys_whitelist =
 ## list of keywords that should be blanked from request object
 ## can be string with comma separated list of words in lowercase
 ## (by default client will always blank keys that contain following words
 ## 'password', 'passwd', 'pwd', 'auth_tkt', 'secret', 'csrf'
 ## this list be extended with additional keywords set here
 appenlight.request_keys_blacklist =
 ## list of namespaces that should be ignores when gathering log entries
 ## can be string with comma separated list of namespaces
 ## (by default the client ignores own entries: appenlight_client.client)
 appenlight.log_namespace_blacklist =
 ################
 ### [sentry] ###
 ################
 ## sentry is a alternative open source error aggregator
 ## you must install python packages `sentry` and `raven` to enable
 sentry.dsn = YOUR_DNS
 sentry.servers =
 sentry.name =
 sentry.key =
 sentry.public_key =
 sentry.secret_key =
 sentry.project =
 sentry.site =
 sentry.include_paths =
 sentry.exclude_paths =
 ################################################################################
-## WARNING: *THE LINE BELOW MUST BE UNCOMMENTED ON A PRODUCTION ENVIRONMENT*  ##
+## WARNING: *DEBUG MODE MUST BE OFF IN A PRODUCTION ENVIRONMENT*              ##
 ## Debug mode will enable the interactive debugging tool, allowing ANYONE to  ##
 ## execute malicious code after an exception is raised.                       ##
 ################################################################################
 #set debug = false
 set debug = true
 #debug = false
 debug = true
 ##################################
 ###       LOGVIEW CONFIG       ###
 ##################################
 logview.sqlalchemy = #faa
@@ @@ -477,32 +328,31 @@ logview.pylons.util = #eee @@
 #########################################################
 ### DB CONFIGS - EACH DB WILL HAVE IT'S OWN CONFIG    ###
 #########################################################
 # SQLITE [default]
 sqlalchemy.db1.url = sqlite:///%(here)s/kallithea.db?timeout=60
 # POSTGRESQL
 #sqlalchemy.db1.url = postgresql://user:pass@localhost/kallithea
 # MySQL
 #sqlalchemy.db1.url = mysql://user:pass@localhost/kallithea
 sqlalchemy.url = sqlite:///%(here)s/kallithea.db?timeout=60
 # see sqlalchemy docs for others
 sqlalchemy.db1.echo = false
 sqlalchemy.db1.pool_recycle = 3600
 sqlalchemy.db1.convert_unicode = true
 sqlalchemy.pool_recycle = 3600
 ################################
 ### ALEMBIC CONFIGURATION   ####
 ################################
 [alembic]
 script_location = kallithea:alembic
 ################################
 ### LOGGING CONFIGURATION   ####
 ################################
 [loggers]
 keys = root, routes, kallithea, sqlalchemy, beaker, templates, whoosh_indexer
+keys = root, routes, kallithea, sqlalchemy, tg, gearbox, beaker, templates, whoosh_indexer, werkzeug, backlash
 [handlers]
 keys = console, console_sql
 [formatters]
 keys = generic, color_formatter, color_formatter_sql
@@ @@ -513,66 +363,93 @@ keys = generic, color_formatter, color_f @@
 [logger_root]
 level = NOTSET
 handlers = console
 [logger_routes]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = routes.middleware
 ## "level = DEBUG" logs the route matched and routing variables.
 propagate = 1
 [logger_beaker]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = beaker.container
 propagate = 1
 [logger_templates]
 #level = WARN
 level = INFO
 handlers =
 qualname = pylons.templating
 propagate = 1
 [logger_kallithea]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = kallithea
 propagate = 1
 [logger_tg]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = tg
 propagate = 1
 [logger_gearbox]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = gearbox
 propagate = 1
 [logger_sqlalchemy]
-level = INFO
+level = WARN
 handlers = console_sql
 qualname = sqlalchemy.engine
 propagate = 0
 [logger_whoosh_indexer]
 #level = WARN
 level = DEBUG
 handlers =
 qualname = whoosh_indexer
 propagate = 1
 [logger_werkzeug]
 level = WARN
 handlers =
 qualname = werkzeug
 propagate = 1
 [logger_backlash]
 level = WARN
 handlers =
 qualname = backlash
 propagate = 1
 ##############
 ## HANDLERS ##
 ##############
 [handler_console]
 class = StreamHandler
 args = (sys.stderr,)
 #level = INFO
 #formatter = generic
 level = DEBUG
 formatter = color_formatter
 [handler_console_sql]
 class = StreamHandler
 args = (sys.stderr,)
 #level = WARN
 #formatter = generic
 level = DEBUG
 formatter = color_formatter_sql
 ################
 ## FORMATTERS ##
 ################

docs/administrator_guide/auth.rst

➞

Show inline comments

@@ file copied from docs/setup.rst to docs/administrator_guide/auth.rst @@
 .. _setup:
 =====
 Setup
 =====
 Setting up Kallithea
 --------------------
 First, you will need to create a Kallithea configuration file. Run the
 following command to do so::
     paster make-config Kallithea my.ini
 This will create the file ``my.ini`` in the current directory. This
 configuration file contains the various settings for Kallithea, e.g.
 proxy port, email settings, usage of static files, cache, Celery
 settings, and logging.
 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
 PostgreSQL, SQLite and MySQL databases. Create the database by running
 the following command::
     paster setup-db 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
 entering this "root" path ``setup-db`` will also prompt you for a username
 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::
     paster setup-db my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos
 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
 location to its database.  (Note: make sure you specify the correct
 path to the root).
 .. 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.
 You are now ready to use Kallithea. To run it simply execute::
     paster serve my.ini
 - This command runs the Kallithea server. The web app should be available at
   http://127.0.0.1:5000. The IP address and port is configurable via the
   configuration file created in the previous step.
 - Log in to Kallithea using the admin account created when running ``setup-db``.
 - The default permissions on each repository is read, and the owner is admin.
   Remember to update these if needed.
 - In the admin panel you can toggle LDAP, anonymous, and permissions
   settings, as well as edit more advanced options on users and
   repositories.
 Extensions
 ----------
 Optionally one can create an ``rcextensions`` package that extends Kallithea
 functionality.
 To generate a skeleton extensions package, run::
     paster make-rcext my.ini
 .. _authentication:
 This will create an ``rcextensions`` package next to the specified ``ini`` file.
 With ``rcextensions`` it's possible to add additional mapping for whoosh,
 stats and add additional code into the push/pull/create/delete repo hooks,
 for example for sending signals to build-bots such as Jenkins.
 See the ``__init__.py`` file inside the generated ``rcextensions`` package
 for more details.
 Using Kallithea with SSH
 ------------------------
 Kallithea currently only hosts repositories using http and https. (The addition
 of ssh hosting is a planned future feature.) However you can easily use ssh in
 parallel with Kallithea. (Repository access via ssh is a standard "out of
 the box" feature of Mercurial_ and you can use this to access any of the
 repositories that Kallithea is hosting. See PublishingRepositories_)
 Kallithea repository structures are kept in directories with the same name
 as the project. When using repository groups, each group is a subdirectory.
 This allows you to easily use ssh for accessing repositories.
 In order to use ssh you need to make sure that your web server and the users'
 login accounts have the correct permissions set on the appropriate directories.
 .. note:: These permissions are independent of any permissions you
           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::
     hg clone ssh://user@kallithea.example.com/srv/repos/kallithea
 Using other external tools such as mercurial-server_ or using ssh key-based
 authentication is fully supported.
 ====================
 Authentication setup
 ====================
 .. note:: In an advanced setup, in order for your ssh access to use
           the same permissions as set up via the Kallithea web
           interface, you can create an authentication hook to connect
           to the Kallithea db and run check functions for permissions
           against that.
 Setting up Whoosh full text search
 ----------------------------------
 Kallithea provides full text search of repositories using `Whoosh`__.
 .. __: https://whoosh.readthedocs.io/en/latest/
 For an incremental index build, run::
     paster make-index my.ini
 For a full index rebuild, run::
     paster make-index my.ini -f
 The ``--repo-location`` option allows the location of the repositories to be overriden;
 usually, the location is retrieved from the Kallithea database.
 The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::
     paster make-index my.ini --index-only=vcs,kallithea
 To keep your index up-to-date it is necessary to do periodic index builds;
 for this, it is recommended to use a crontab entry. Example::
 3  *  *  *  /path/to/virtualenv/bin/paster make-index /path/to/kallithea/my.ini
 When using incremental mode (the default), Whoosh will check the last
 modification date of each file and add it to be reindexed if a newer file is
 available. The indexing daemon checks for any removed files and removes them
 from index.
 If you want to rebuild the index from scratch, you can use the ``-f`` flag as above,
 or in the admin panel you can check the "build from scratch" checkbox.
 Users can be authenticated in different ways. By default, Kallithea
 uses its internal user database. Alternative authentication
 methods include LDAP, PAM, Crowd, and container-based authentication.
 .. _ldap-setup:
 Setting up LDAP support
 -----------------------
 LDAP Authentication
 -------------------
 Kallithea supports LDAP authentication. In order
 to use LDAP, you have to install the python-ldap_ package. This package is
 available via PyPI, so you can install it by running::
     pip install python-ldap
@@ @@ -175,16 +29,15 @@ and then *Save*, to enable the LDAP plug @@
 Here's a typical LDAP setup::
  Connection settings
  Enable LDAP          = checked
  Host                 = host.example.com
  Port                 = 389
  Account              = <account>
  Password             = <password>
- Connection Security  = LDAPS connection
  Connection Security  = LDAPS
  Certificate Checks   = DEMAND
  Search settings
  Base DN              = CN=users,DC=host,DC=example,DC=org
  LDAP Filter          = (&(objectClass=user)(!(objectClass=computer)))
  LDAP Search Scope    = SUBTREE
@@ @@ -212,14 +65,15 @@ Enable LDAP : required @@
 Host : required
     LDAP server hostname or IP address. Can be also a comma separated
     list of servers to support LDAP fail-over.
 .. _Port:
 Port : required
 for un-encrypted LDAP, 636 for SSL-encrypted LDAP.
 Port : optional
     Defaults to 389 for PLAIN un-encrypted LDAP and START_TLS.
     Defaults to 636 for LDAPS.
 .. _ldap_account:
 Account : optional
     Only required if the LDAP server does not allow anonymous browsing of
     records.  This should be a special account for record browsing.  This
@@ @@ -233,32 +87,33 @@ Password : optional @@
 .. _Enable LDAPS:
 Connection Security : required
     Defines the connection to LDAP server
     No encryption
         Plain non encrypted connection
     PLAIN
         Plain unencrypted LDAP connection.
         This will by default use `Port`_ 389.
     LDAPS connection
         Enable LDAPS connections. It will likely require `Port`_ to be set to
         a different value (standard LDAPS port is 636). When LDAPS is enabled
         then `Certificate Checks`_ is required.
     LDAPS
         Use secure LDAPS connections according to `Certificate
         Checks`_ configuration.
         This will by default use `Port`_ 636.
     START_TLS on LDAP connection
         START TLS connection
     START_TLS
         Use START TLS according to `Certificate Checks`_ configuration on an
         apparently "plain" LDAP connection.
         This will by default use `Port`_ 389.
 .. _Certificate Checks:
 Certificate Checks : optional
     How SSL certificates verification is handled -- this is only useful when
     `Enable LDAPS`_ is enabled.  Only DEMAND or HARD offer full SSL security
     while the other options are susceptible to man-in-the-middle attacks.  SSL
     certificates can be installed to /etc/openldap/cacerts so that the
     DEMAND or HARD options can be used with self-signed certificates or
     certificates that do not have traceable certificates of authority.
     with mandatory certificate validation, while the other options are
     susceptible to man-in-the-middle attacks.
     NEVER
         A serve certificate will never be requested or checked.
     ALLOW
         A server certificate is requested.  Failure to provide a
@@ @@ -274,12 +129,22 @@ Certificate Checks : optional @@
         A server certificate is requested and must be provided and
         authenticated for the session to proceed.
     HARD
         The same as DEMAND.
 .. _Custom CA Certificates:
 Custom CA Certificates : optional
     Directory used by OpenSSL to find CAs for validating the LDAP server certificate.
     Python 2.7.10 and later default to using the system certificate store, and
     this should thus not be necessary when using certificates signed by a CA
     trusted by the system.
     It can be set to something like `/etc/openldap/cacerts` on older systems or
     if using self-signed certificates.
 .. _Base DN:
 Base DN : required
     The Distinguished Name (DN) where searches for users will be performed.
     Searches can be controlled by `LDAP Filter`_ and `LDAP Search Scope`_.
@@ @@ -344,13 +209,13 @@ user update in Kallithea. @@
 If You have problems with LDAP access and believe You entered correct
 information check out the Kallithea logs, any error messages sent from LDAP
 will be saved there.
 Active Directory
-''''''''''''''''
+^^^^^^^^^^^^^^^^
 Kallithea can use Microsoft Active Directory for user authentication.  This
 is done through an LDAP or LDAPS connection to Active Directory.  The
 following LDAP configuration settings are typical for using Active
 Directory ::
@@ @@ -381,30 +246,30 @@ a matching user account is created in Ka @@
 administrator can then modify it using Kallithea's admin interface.
 It's also possible for an administrator to create accounts and configure their
 permissions before the user logs in for the first time, using the :ref:`create-user` API.
 Container-based authentication
-''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In a container-based authentication setup, Kallithea reads the user name from
 the ``REMOTE_USER`` server variable provided by the WSGI container.
-After setting up your container (see `Apache with mod_wsgi`_), you'll need
+After setting up your container (see :ref:`apache_mod_wsgi`), you'll need
 to configure it to require authentication on the location configured for
 Kallithea.
 Proxy pass-through authentication
-'''''''''''''''''''''''''''''''''
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In a proxy pass-through authentication setup, Kallithea reads the user name
 from the ``X-Forwarded-User`` request header, which should be configured to be
 sent by the reverse-proxy server.
 After setting up your proxy solution (see `Apache virtual host reverse proxy example`_,
 `Apache as subdirectory`_ or `Nginx virtual host example`_), you'll need to
 After setting up your proxy solution (see :ref:`apache_virtual_host_reverse_proxy`,
 :ref:`apache_subdirectory` or :ref:`nginx_virtual_host`), you'll need to
 configure the authentication and add the username in a request header named
 ``X-Forwarded-User``.
 For example, the following config section for Apache sets a subdirectory in a
 reverse-proxy setup with basic auth:
@@ @@ -425,394 +290,81 @@ reverse-proxy setup with basic auth: @@
       RewriteEngine On
       RewriteCond %{LA-U:REMOTE_USER} (.+)
       RewriteRule .* - [E=RU:%1]
       RequestHeader set X-Forwarded-User %{RU}e
     </Location>
 Setting metadata in container/reverse-proxy
 """""""""""""""""""""""""""""""""""""""""""
 When a new user account is created on the first login, Kallithea has no information about
 the user's email and full name. So you can set some additional request headers like in the
 example below. In this example the user is authenticated via Kerberos and an Apache
 mod_python fixup handler is used to get the user information from a LDAP server. But you
 could set the request headers however you want.
 .. code-block:: apache
     <Location /someprefix>
       ProxyPass http://127.0.0.1:5000/someprefix
       ProxyPassReverse http://127.0.0.1:5000/someprefix
       SetEnvIf X-Url-Scheme https HTTPS=1
       AuthName "Kerberos Login"
       AuthType Kerberos
       Krb5Keytab /etc/apache2/http.keytab
       KrbMethodK5Passwd off
       KrbVerifyKDC on
       Require valid-user
       PythonFixupHandler ldapmetadata
       RequestHeader set X_REMOTE_USER %{X_REMOTE_USER}e
       RequestHeader set X_REMOTE_EMAIL %{X_REMOTE_EMAIL}e
       RequestHeader set X_REMOTE_FIRSTNAME %{X_REMOTE_FIRSTNAME}e
       RequestHeader set X_REMOTE_LASTNAME %{X_REMOTE_LASTNAME}e
     </Location>
 .. code-block:: python
     from mod_python import apache
     import ldap
     LDAP_SERVER = "ldaps://server.mydomain.com:636"
     LDAP_USER = ""
     LDAP_PASS = ""
     LDAP_ROOT = "dc=mydomain,dc=com"
     LDAP_FILTER = "sAMAccountName=%s"
     LDAP_ATTR_LIST = ['sAMAccountName','givenname','sn','mail']
     def fixuphandler(req):
         if req.user is None:
             # no user to search for
             return apache.OK
         else:
             try:
                 if('\\' in req.user):
                     username = req.user.split('\\')[1]
                 elif('@' in req.user):
                     username = req.user.split('@')[0]
                 else:
                     username = req.user
                 l = ldap.initialize(LDAP_SERVER)
                 l.simple_bind_s(LDAP_USER, LDAP_PASS)
                 r = l.search_s(LDAP_ROOT, ldap.SCOPE_SUBTREE, LDAP_FILTER % username, attrlist=LDAP_ATTR_LIST)
                 req.subprocess_env['X_REMOTE_USER'] = username
                 req.subprocess_env['X_REMOTE_EMAIL'] = r[0][1]['mail'][0].lower()
                 req.subprocess_env['X_REMOTE_FIRSTNAME'] = "%s" % r[0][1]['givenname'][0]
                 req.subprocess_env['X_REMOTE_LASTNAME'] = "%s" % r[0][1]['sn'][0]
             except Exception, e:
                 apache.log_error("error getting data from ldap %s" % str(e), apache.APLOG_ERR)
             return apache.OK
 .. note::
    If you enable proxy pass-through authentication, make sure your server is
    only accessible through the proxy. Otherwise, any client would be able to
    forge the authentication header and could effectively become authenticated
    using any account of their liking.
 Integration with issue trackers
 -------------------------------
 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_server_link = https://issues.example.com/{repo}/issue/{id}
     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.
 The default expression matches issues in the format ``#<number>``, e.g., ``#300``.
 Matched issue references are replaced with the link specified in
 ``issue_server_link``. ``{id}`` is replaced with the issue ID, and
 ``{repo}`` with the repository name.  Since the # is stripped away,
 ``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
   <a href="https://issues.example.com/example_repo/issue/300">ISSUE-300</a>
 If needed, more than one pattern can be specified by appending a unique suffix to
 the variables. For example::
     issue_pat_wiki = (?:wiki-)(.+)
     issue_server_link_wiki = https://wiki.example.com/{id}
     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
   <a href="https://wiki.example.com/some-id">WIKI-some-id</a>
 Hook management
 ---------------
 Hooks can be managed in similar way to that used in ``.hgrc`` files.
 To manage hooks, choose *Admin > Settings > Hooks*.
 The built-in hooks cannot be modified, though they can be enabled or disabled in the *VCS* section.
 To add another custom hook simply fill in the first textbox with
 ``<name>.<hook_type>`` and the second with the hook path. Example hooks
 can be found in ``kallithea.lib.hooks``.
 Changing default encoding
 -------------------------
 By default, Kallithea uses UTF-8 encoding.
 This is configurable as ``default_encoding`` in the .ini file.
 This affects many parts in Kallithea including user names, filenames, and
 encoding of commit messages. In addition Kallithea can detect if the ``chardet``
 library is installed. If ``chardet`` is detected Kallithea will fallback to it
 when there are encode/decode errors.
 Celery configuration
 --------------------
 Kallithea can use the distributed task queue system Celery_ to run tasks like
 cloning repositories or sending emails.
 Kallithea will in most setups work perfectly fine out of the box (without
 Celery), executing all tasks in the web server process. Some tasks can however
 take some time to run and it can be better to run such tasks asynchronously in
 a separate process so the web server can focus on serving web requests.
 For installation and configuration of Celery, see the `Celery documentation`_.
 Note that Celery requires a message broker service like RabbitMQ_ (recommended)
 or Redis_.
 The use of Celery is configured in the Kallithea ini configuration file.
 To enable it, simply set::
   use_celery = true
 and add or change the ``celery.*`` and ``broker.*`` configuration variables.
 Remember that the ini files use the format with '.' and not with '_' like
 Celery. So for example setting `BROKER_HOST` in Celery means setting
 `broker.host` in the configuration file.
 To start the Celery process, run::
  paster celeryd <configfile.ini>
 .. note::
    Make sure you run this command from the same virtualenv, and with the same
    user that Kallithea runs.
 HTTPS support
 -------------
 Kallithea will by default generate URLs based on the WSGI environment.
 Alternatively, you can use some special configuration settings to control
 directly which scheme/protocol Kallithea will use when generating URLs:
 - With ``https_fixup = true``, the scheme will be taken from the
   ``X-Url-Scheme``, ``X-Forwarded-Scheme`` or ``X-Forwarded-Proto`` HTTP header
   (default ``http``).
 - With ``force_https = true`` the default will be ``https``.
 - With ``use_htsts = true``, Kallithea will set ``Strict-Transport-Security`` when using https.
 Nginx virtual host example
 --------------------------
 Sample config for Nginx using proxy:
 .. code-block:: nginx
     upstream kallithea {
         server 127.0.0.1:5000;
         # add more instances for load balancing
         #server 127.0.0.1:5001;
         #server 127.0.0.1:5002;
+    }
     ## gist alias
     server {
        listen          443;
        server_name     gist.example.com;
        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;
        rewrite ^/(.+)$ https://kallithea.example.com/_admin/gists/$1;
        rewrite (.*)    https://kallithea.example.com/_admin/gists;
+    }
     server {
        listen          443;
        server_name     kallithea.example.com
        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;
        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;
        ## uncomment root directive if you want to serve static files by nginx
        ## requires static_files = false in .ini file
        #root /path/to/installation/kallithea/public;
        include         /etc/nginx/proxy.conf;
        location / {
             try_files $uri @kallithea;
+       }
        location @kallithea {
             proxy_pass      http://127.0.0.1:5000;
+       }
+    }
 Here's the proxy.conf. It's tuned so it will not timeout on long
 pushes or large pushes::
     proxy_redirect              off;
     proxy_set_header            Host $host;
     ## needed for container auth
     #proxy_set_header            REMOTE_USER $remote_user;
     #proxy_set_header            X-Forwarded-User $remote_user;
     proxy_set_header            X-Url-Scheme $scheme;
     proxy_set_header            X-Host $http_host;
     proxy_set_header            X-Real-IP $remote_addr;
     proxy_set_header            X-Forwarded-For $proxy_add_x_forwarded_for;
     proxy_set_header            Proxy-host $proxy_host;
     proxy_buffering             off;
     proxy_connect_timeout       7200;
     proxy_send_timeout          7200;
     proxy_read_timeout          7200;
     proxy_buffers               8 32k;
     client_max_body_size        1024m;
     client_body_buffer_size     128k;
     large_client_header_buffers 8 64k;
 Apache virtual host reverse proxy example
 -----------------------------------------
 Here is a sample configuration file for Apache using proxy:
 .. code-block:: apache
     <VirtualHost *:80>
             ServerName kallithea.example.com
             <Proxy *>
               # For Apache 2.4 and later:
               Require all granted
               # For Apache 2.2 and earlier, instead use:
               # Order allow,deny
               # Allow from all
             </Proxy>
             #important !
             #Directive to properly generate url (clone url) for pylons
             ProxyPreserveHost On
             #kallithea instance
             ProxyPass / http://127.0.0.1:5000/
             ProxyPassReverse / http://127.0.0.1:5000/
             #to enable https use line below
             #SetEnvIf X-Url-Scheme https HTTPS=1
     </VirtualHost>
 Additional tutorial
 http://pylonsbook.com/en/1.1/deployment.html#using-apache-to-proxy-requests-to-pylons
 Apache as subdirectory
 ----------------------
 Apache subdirectory part:
 .. code-block:: apache
     <Location /<someprefix> >
       ProxyPass http://127.0.0.1:5000/<someprefix>
       ProxyPassReverse http://127.0.0.1:5000/<someprefix>
       SetEnvIf X-Url-Scheme https HTTPS=1
     </Location>
 Besides the regular apache setup you will need to add the following line
 into ``[app:main]`` section of your .ini file::
     filter-with = proxy-prefix
 Add the following at the end of the .ini file::
     [filter:proxy-prefix]
     use = egg:PasteDeploy#prefix
     prefix = /<someprefix>
 then change ``<someprefix>`` into your chosen prefix
 Apache with mod_wsgi
 --------------------
 Alternatively, Kallithea can be set up with Apache under mod_wsgi. For
 that, you'll need to:
 - Install mod_wsgi. If using a Debian-based distro, you can install
   the package libapache2-mod-wsgi::
     aptitude install libapache2-mod-wsgi
 - Enable mod_wsgi::
     a2enmod wsgi
 - Add global Apache configuration to tell mod_wsgi that Python only will be
   used in the WSGI processes and shouldn't be initialized in the Apache
   processes::
     WSGIRestrictEmbedded On
 - Create a wsgi dispatch script, like the one below. Make sure you
   check that the paths correctly point to where you installed Kallithea
   and its Python Virtual Environment.
 - Enable the ``WSGIScriptAlias`` directive for the WSGI dispatch script,
   as in the following example. Once again, check the paths are
   correctly specified.
 Here is a sample excerpt from an Apache Virtual Host configuration file:
 .. code-block:: apache
     WSGIDaemonProcess kallithea processes=5 threads=1 maximum-requests=100 \
         python-home=/srv/kallithea/venv
     WSGIProcessGroup kallithea
     WSGIScriptAlias / /srv/kallithea/dispatch.wsgi
     WSGIPassAuthorization On
 Or if using a dispatcher WSGI script with proper virtualenv activation:
 .. code-block:: apache
     WSGIDaemonProcess kallithea processes=5 threads=1 maximum-requests=100
     WSGIProcessGroup kallithea
     WSGIScriptAlias / /srv/kallithea/dispatch.wsgi
     WSGIPassAuthorization On
 Apache will by default run as a special Apache user, on Linux systems
 usually ``www-data`` or ``apache``. If you need to have the repositories
 directory owned by a different user, use the user and group options to
 WSGIDaemonProcess to set the name of the user and group.
 .. note::
    If running Kallithea in multiprocess mode,
    make sure you set ``instance_id = *`` in the configuration so each process
    gets it's own cache invalidation key.
 Example WSGI dispatch script:
 .. code-block:: python
     import os
     os.environ["HGENCODING"] = "UTF-8"
     os.environ['PYTHON_EGG_CACHE'] = '/srv/kallithea/.egg-cache'
     # sometimes it's needed to set the curent dir
     os.chdir('/srv/kallithea/')
     import site
     site.addsitedir("/srv/kallithea/venv/lib/python2.7/site-packages")
     ini = '/srv/kallithea/my.ini'
     from paste.script.util.logging_config import fileConfig
     fileConfig(ini)
     from paste.deploy import loadapp
     application = loadapp('config:' + ini)
 Or using proper virtualenv activation:
 .. code-block:: python
     activate_this = '/srv/kallithea/venv/bin/activate_this.py'
     execfile(activate_this, dict(__file__=activate_this))
     import os
     os.environ['HOME'] = '/srv/kallithea'
     ini = '/srv/kallithea/kallithea.ini'
     from paste.script.util.logging_config import fileConfig
     fileConfig(ini)
     from paste.deploy import loadapp
     application = loadapp('config:' + ini)
 Other configuration files
 -------------------------
 A number of `example init.d scripts`__ can be found in
 the ``init.d`` directory of the Kallithea source.
 .. __: https://kallithea-scm.org/repos/kallithea/files/tip/init.d/ .
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _python: http://www.python.org/
 .. _Mercurial: https://www.mercurial-scm.org/
 .. _Celery: http://celeryproject.org/
 .. _Celery documentation: http://docs.celeryproject.org/en/latest/getting-started/index.html
 .. _RabbitMQ: http://www.rabbitmq.com/
 .. _Redis: http://redis.io/
 .. _python-ldap: http://www.python-ldap.org/
 .. _mercurial-server: http://www.lshift.net/mercurial-server.html
 .. _PublishingRepositories: https://www.mercurial-scm.org/wiki/PublishingRepositories

docs/administrator_guide/vcs_setup.rst

➞

Show inline comments

-.. _vcs_support:
+.. _vcs_setup:
 ===============================
 Version control systems support
 ===============================
 =============================
 Version control systems setup
 =============================
 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.
 file ``kallithea/__init__.py`` and commenting out the backend. For example, to
 disable Git but keep Mercurial enabled:
 .. code-block:: python
    BACKENDS = {
        'hg': 'Mercurial repository',
        #'git': 'Git repository',
+   }
 Git support
 -----------
 Git-specific setup
 ------------------
 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
+waitress_ for `gearbox serve` instead of the built-in `paste` WSGI
 server.
-The paster server is controlled in the .ini file::
+The web server used by gearbox is controlled in the .ini file::
     use = egg:waitress#main
 or::
     use = egg:gunicorn#main
@@ @@ -42,46 +43,19 @@ or:: @@
 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::
 Increasing Git HTTP POST buffer size
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
     ## 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
 If Git pushes fail with HTTP error code 411 (Length Required), you may need to
 increase the Git HTTP POST buffer. Run the following command as the user that
 runs Kallithea to set a global Git variable to this effect::
     ## 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.
     git config --global http.postBuffer 524288000
 .. _waitress: http://pypi.python.org/pypi/waitress
 .. _gunicorn: http://pypi.python.org/pypi/gunicorn
 .. _subrepositories: http://mercurial.aragost.com/kick-start/en/subrepositories/

docs/api/api.rst

➞

Show inline comments

@@ @@ -6,40 +6,22 @@ API @@
 Kallithea has a simple JSON RPC API with a single schema for calling all API
 methods. Everything is available by sending JSON encoded http(s) requests to
 ``<your_server>/_admin/api``.
 API access for web views
 ++++++++++++++++++++++++
 API access can also be turned on for each web view in Kallithea that is
 decorated with the ``@LoginRequired`` decorator. Some views use
 ``@LoginRequired(api_access=True)`` and are always available. By default only
 RSS/Atom feed views are enabled. Other views are
 only available if they have been whitelisted. Edit the
 ``api_access_controllers_whitelist`` option in your .ini file and define views
 that should have API access enabled.
 API keys
 --------
 For example, to enable API access to patch/diff, raw file and archive::
     api_access_controllers_whitelist =
         ChangesetController:changeset_patch,
         ChangesetController:changeset_raw,
         FilesController:raw,
         FilesController:archivefile
 After this change, a Kallithea view can be accessed without login by adding a
 GET parameter ``?api_key=<api_key>`` to the URL.
 Exposing raw diffs is a good way to integrate with
 third-party services like code review, or build farms that can download archives.
 Every Kallithea user automatically receives an API key, which they can
 view under "My Account". On this page, API keys can also be revoked, and
 additional API keys can be generated.
 API access
-++++++++++
+----------
 Clients must send JSON encoded JSON-RPC requests::
+    {
         "id: "<id>",
         "api_key": "<api_key>",
@@ @@ -73,13 +55,13 @@ The response to the JSON-RPC API call wi @@
 All responses from the API will be ``HTTP/1.0 200 OK``. If an error occurs,
 the reponse will have a failure description in *error* and
 *result* will be null.
 API client
-++++++++++
+----------
 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``::
@@ @@ -107,17 +89,17 @@ To avoid specifying ``apihost`` and ``ap @@
 This will create a ``~/.config/kallithea`` with the specified URL and API key
 so you don't have to specify them every time.
 API methods
-+++++++++++
+-----------
 pull
-----
+^^^^
 Pull the given repo from remote location. Can be used to automatically keep
 remote repos up to date.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -133,13 +115,13 @@ OUTPUT:: @@
     id : <id_given_in_input>
     result : "Pulled from `<reponame>`"
     error :  null
 rescan_repos
-------------
+^^^^^^^^^^^^
 Rescan repositories. If ``remove_obsolete`` is set,
 Kallithea will delete repos that are in the database but not in the filesystem.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -156,13 +138,13 @@ OUTPUT:: @@
     id : <id_given_in_input>
     result : "{'added': [<list of names of added repos>],
                'removed': [<list of names of removed repos>]}"
     error :  null
 invalidate_cache
-----------------
+^^^^^^^^^^^^^^^^
 Invalidate the cache for a repository.
 This command can only be executed using the api_key of a user with admin rights,
 or that of a regular user with admin or write access to the repository.
 INPUT::
@@ @@ -178,13 +160,13 @@ OUTPUT:: @@
     id : <id_given_in_input>
     result : "Caches of repository `<reponame>`"
     error :  null
 lock
-----
+^^^^
 Set the locking state on the given repository by the given user.
 If the param ``userid`` is skipped, it is set to the ID of the user who is calling this method.
 If param ``locked`` is skipped, the current lock state of the repository is returned.
 This command can only be executed using the api_key of a user with admin rights, or that of a regular user with admin or write access to the repository.
@@ @@ -209,13 +191,13 @@ OUTPUT:: @@
                  "locked_by": "<username>",
                  "msg": "User `<username>` set lock state for repo `<reponame>` to `<false|true>`"
+             }
     error :  null
 get_ip
-------
+^^^^^^
 Return IP address as seen from Kallithea server, together with all
 defined IP addresses for given user.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -241,18 +223,18 @@ OUTPUT:: @@
+                             ]
+             }
     error :  null
 get_user
---------
+^^^^^^^^
 Get a user by username or userid. The result is empty if user can't be found.
 If userid param is skipped, it is set to id of user who is calling this method.
 Any userid can be specified when the command is executed using the api_key of a user with admin rights.
-Regular users can only speicy their own userid.
+Regular users can only specify their own userid.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method :  "get_user"
@@ @@ -285,13 +267,13 @@ OUTPUT:: @@
                     "repositories_groups": {"Group1": "group.read"}
                  },
+            }
     error:  null
 get_users
----------
+^^^^^^^^^
 List all existing users.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -322,13 +304,13 @@ OUTPUT:: @@
+            ]
     error:  null
 .. _create-user:
 create_user
------------
+^^^^^^^^^^^
 Create new user.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -368,13 +350,13 @@ OUTPUT:: @@
 Example::
     kallithea-api create_user username:bent email:bent@example.com firstname:Bent lastname:Bentsen extern_type:ldap extern_name:uid=bent,dc=example,dc=com
 update_user
------------
+^^^^^^^^^^^
 Update the given user if such user exists.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -412,13 +394,13 @@ OUTPUT:: @@
                 "last_login": "<last_login>",
               },
+            }
     error:  null
 delete_user
------------
+^^^^^^^^^^^
 Delete the given user if such a user exists.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -436,13 +418,13 @@ OUTPUT:: @@
               "msg" : "deleted user ID:<userid> <username>",
               "user": null
+            }
     error:  null
 get_user_group
---------------
+^^^^^^^^^^^^^^
 Get an existing user group.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -478,13 +460,13 @@ OUTPUT:: @@
                               …
+                            ]
+             }
     error : null
 get_user_groups
----------------
+^^^^^^^^^^^^^^^
 List all existing user groups.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -504,13 +486,13 @@ OUTPUT:: @@
                },
                …
+              ]
     error : null
 create_user_group
------------------
+^^^^^^^^^^^^^^^^^
 Create a new user group.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -534,13 +516,13 @@ OUTPUT:: @@
                      "active":          "<bool>",
                },
+            }
     error:  null
 add_user_to_user_group
-----------------------
+^^^^^^^^^^^^^^^^^^^^^^
 Adds a user to a user group. If the user already is in that group, success will be
 ``false``.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -561,13 +543,13 @@ OUTPUT:: @@
               "msg": "added member `<username>` to a user group `<groupname>` |
                       User is already in that group"
+            }
     error:  null
 remove_user_from_user_group
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Remove a user from a user group. If the user isn't in the given group, success will
 be ``false``.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -588,26 +570,28 @@ OUTPUT:: @@
               "msg": "removed member <username> from user group <groupname> |
                       User wasn't in group"
+            }
     error:  null
 get_repo
---------
+^^^^^^^^
 Get an existing repository by its name or repository_id. Members will contain
 either users_group or users associated to that repository.
 This command can only be executed using the api_key of a user with admin rights,
 or that of a regular user with at least read access to the repository.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method :  "get_repo"
     args:     {
                 "repoid" : "<reponame or repo_id>"
                 "repoid" : "<reponame or repo_id>",
                 "with_revision_names": "<bool> = Optional(False)",
                 "with_pullrequests": "<bool> = Optional(False)",
+              }
 OUTPUT::
     id : <id_given_in_input>
     result: None if repository does not exist or
@@ @@ -627,13 +611,13 @@ OUTPUT:: @@
                                        "author":   "<full_author>",
                                        "date":     "<date_time_of_commit>",
                                        "message":  "<commit_message>",
                                        "raw_id":   "<raw_id>",
                                        "revision": "<numeric_revision>",
                                        "short_id": "<short_id>"
+                                     }
+                                     },
                 "owner":             "<repo_owner>",
                 "fork_of":           "<name_of_fork_parent>",
                 "members" :     [
+                                  {
                                     "type":        "user",
                                     "user_id" :    "<user_id>",
@@ @@ -655,13 +639,13 @@ OUTPUT:: @@
                                     "id" :       "<usersgroupid>",
                                     "name" :     "<usersgroupname>",
                                     "active":    "<bool>",
                                     "permission" : "repository.(read|write|admin)"
                                   },
                                   …
+                                ]
+                                ],
                  "followers":   [
+                                  {
                                     "user_id" :     "<user_id>",
                                     "username" :    "<username>",
                                     "api_key" :     "<api_key>",
                                     "firstname":    "<firstname>",
@@ @@ -672,18 +656,80 @@ OUTPUT:: @@
                                     "active" :      "<bool>",
                                     "admin" :       "<bool>",
                                     "ldap_dn" :     "<ldap_dn>",
                                     "last_login":   "<last_login>",
                                   },
                                   …
+                 ]
                                 ],
                  <if with_revision_names == True>
                  "tags": {
                             "<tagname>": "<raw_id>",
                             ...
                          },
                  "branches": {
                             "<branchname>": "<raw_id>",
                             ...
                          },
                  "bookmarks": {
                             "<bookmarkname>": "<raw_id>",
                             ...
                          },
                 <if with_pullrequests == True>
                 "pull_requests": [
+                  {
                     "status": "<pull_request_status>",
                     "pull_request_id": <pull_request_id>,
                     "description": "<pull_request_description>",
                     "title": "<pull_request_title>",
                     "url": "<pull_request_url>",
                     "reviewers": [
+                      {
                         "username": "<user_id>",
                       },
                       ...
                     ],
                     "org_repo_url": "<repo_url>",
                     "org_ref_parts": [
                       "<ref_type>",
                       "<ref_name>",
                       "<raw_id>"
                     ],
                     "other_ref_parts": [
                       "<ref_type>",
                       "<ref_name>",
                       "<raw_id>"
                     ],
                     "comments": [
+                      {
                         "username": "<user_id>",
                         "text": "<comment text>",
                         "comment_id": "<comment_id>",
                       },
                       ...
                     ],
                     "owner": "<username>",
                     "statuses": [
+                      {
                         "status": "<status_of_review>",        # "under_review", "approved" or "rejected"
                         "reviewer": "<user_id>",
                         "modified_at": "<date_time_of_review>" # iso 8601 date, server's timezone
                       },
                       ...
                     ],
                     "revisions": [
                       "<raw_id>",
                       ...
+                    ]
                   },
                   ...
+                ]
+            }
     error:  null
 get_repos
----------
+^^^^^^^^^
 List all existing repositories.
 This command can only be executed using the api_key of a user with admin rights,
 or that of a regular user with at least read access to the repository.
 INPUT::
@@ @@ -714,13 +760,13 @@ OUTPUT:: @@
               },
               …
+            ]
     error:  null
 get_repo_nodes
---------------
+^^^^^^^^^^^^^^
 Return a list of files and directories for a given path at the given revision.
 It is possible to specify ret_type to show only ``files`` or ``dirs``.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -745,13 +791,13 @@ OUTPUT:: @@
               },
               …
+            ]
     error:  null
 create_repo
------------
+^^^^^^^^^^^
 Create a repository. If the repository name contains "/", the repository will be
 created in the repository group indicated by that path. Any such repository
 groups need to exist before calling this method, or the call will fail.
 For example "foo/bar/baz" will create a repository "baz" inside the repository
 group "bar" which itself is in a repository group "foo", but both "foo" and
@@ @@ -799,13 +845,13 @@ OUTPUT:: @@
                 "enable_statistics": "<bool>",
               },
+            }
     error:  null
 update_repo
------------
+^^^^^^^^^^^
 Update a repository.
 This command can only be executed using the api_key of a user with admin rights,
 or that of a regular user with create repository permission.
 Regular users cannot specify owner parameter.
@@ @@ -859,13 +905,13 @@ OUTPUT:: @@
                 "locked_date": "<float lock_time>",
               },
+            }
     error:  null
 fork_repo
----------
+^^^^^^^^^
 Create a fork of the given repo. If using Celery, this will
 return success message immediately and a fork will be created
 asynchronously.
 This command can only be executed using the api_key of a user with admin
 rights, or with the global fork permission, by a regular user with create
@@ @@ -895,13 +941,13 @@ OUTPUT:: @@
               "msg": "Created fork of `<reponame>` as `<forkname>`",
               "success": true
+            }
     error:  null
 delete_repo
------------
+^^^^^^^^^^^
 Delete a repository.
 This command can only be executed using the api_key of a user with admin rights,
 or that of a regular user with admin access to the repository.
 When ``forks`` param is set it is possible to detach or delete forks of the deleted repository.
@@ @@ -922,13 +968,13 @@ OUTPUT:: @@
               "msg": "Deleted repository `<reponame>`",
               "success": true
+            }
     error:  null
 grant_user_permission
----------------------
+^^^^^^^^^^^^^^^^^^^^^
 Grant permission for a user on the given repository, or update the existing one if found.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -948,13 +994,13 @@ OUTPUT:: @@
               "msg" : "Granted perm: `<perm>` for user: `<username>` in repo: `<reponame>`",
               "success": true
+            }
     error:  null
 revoke_user_permission
-----------------------
+^^^^^^^^^^^^^^^^^^^^^^
 Revoke permission for a user on the given repository.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -973,13 +1019,13 @@ OUTPUT:: @@
               "msg" : "Revoked perm for user: `<username>` in repo: `<reponame>`",
               "success": true
+            }
     error:  null
 grant_user_group_permission
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Grant permission for a user group on the given repository, or update the
 existing one if found.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -1000,13 +1046,13 @@ OUTPUT:: @@
               "msg" : "Granted perm: `<perm>` for group: `<usersgroupname>` in repo: `<reponame>`",
               "success": true
+            }
     error:  null
 revoke_user_group_permission
-----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Revoke permission for a user group on the given repository.
 This command can only be executed using the api_key of a user with admin rights.
 INPUT::
@@ @@ -1023,6 +1069,238 @@ OUTPUT:: @@
     id : <id_given_in_input>
     result: {
               "msg" : "Revoked perm for group: `<usersgroupname>` in repo: `<reponame>`",
               "success": true
+            }
     error:  null
 get_changesets
 ^^^^^^^^^^^^^^
 Get changesets of a given repository. This command can only be executed using the api_key
 of a user with read permissions to the repository.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method  : "get_changesets"
     args:     {
                 "repoid" : "<reponame or repo_id>",
                 "start": "<revision number> = Optional(None)",
                 "end": "<revision number> = Optional(None)",
                 "start_date": "<date> = Optional(None)",    # in "%Y-%m-%dT%H:%M:%S" format
                 "end_date": "<date> = Optional(None)",      # in "%Y-%m-%dT%H:%M:%S" format
                 "branch_name": "<branch name filter> = Optional(None)",
                 "reverse": "<bool> = Optional(False)",
                 "with_file_list": "<bool> = Optional(False)"
+              }
 OUTPUT::
     id : <id_given_in_input>
     result: [
+    {
       "raw_id": "<raw_id>",
       "short_id": "short_id": "<short_id>",
       "author": "<full_author>",
       "date": "<date_time_of_commit>",
       "message": "<commit_message>",
       "revision": "<numeric_revision>",
       <if with_file_list == True>
       "added": [<list of added files>],
       "changed": [<list of changed files>],
       "removed": [<list of removed files>]
     },
     ...
+    ]
     error:  null
 get_changeset
 ^^^^^^^^^^^^^
 Get information and review status for a given changeset. This command can only
 be executed using the api_key of a user with read permissions to the
 repository.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method  : "get_changeset"
     args:     {
                 "repoid" : "<reponame or repo_id>",
                 "raw_id" : "<raw_id>",
                 "with_reviews": "<bool> = Optional(False)"
+              }
 OUTPUT::
     id : <id_given_in_input>
     result: {
               "author":   "<full_author>",
               "date":     "<date_time_of_commit>",
               "message":  "<commit_message>",
               "raw_id":   "<raw_id>",
               "revision": "<numeric_revision>",
               "short_id": "<short_id>",
               "reviews": [{
                     "reviewer":   "<username>",
                     "modified_at": "<date_time_of_review>",  # iso 8601 date, server's timezone
                     "status":   "<status_of_review>",        # "under_review", "approved" or "rejected"
                  },
                  ...
+              ]
+            }
     error:  null
 Example output::
+    {
       "id" : 1,
       "error" : null,
       "result" : {
         "author" : {
           "email" : "user@example.com",
           "name" : "Kallithea Admin"
         },
         "changed" : [],
         "short_id" : "e1022d3d28df",
         "date" : "2017-03-28T09:09:03",
         "added" : [
           "README.rst"
         ],
         "removed" : [],
         "revision" : 0,
         "raw_id" : "e1022d3d28dfba02f626cde65dbe08f4ceb0e4e7",
         "message" : "Added file via Kallithea",
         "id" : "e1022d3d28dfba02f626cde65dbe08f4ceb0e4e7",
         "reviews" : [
+          {
             "status" : "under_review",
             "modified_at" : "2017-03-28T09:17:08.618",
             "reviewer" : "user"
+          }
+        ]
+      }
+    }
 get_pullrequest
 ^^^^^^^^^^^^^^^
 Get information and review status for a given pull request. This command can only be executed
 using the api_key of a user with read permissions to the original repository.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method  : "get_pullrequest"
     args:     {
                 "pullrequest_id" : "<pullrequest_id>",
+              }
 OUTPUT::
     id : <id_given_in_input>
     result: {
         "status": "<pull_request_status>",
         "pull_request_id": <pull_request_id>,
         "description": "<pull_request_description>",
         "title": "<pull_request_title>",
         "url": "<pull_request_url>",
         "reviewers": [
+          {
             "username": "<user_name>",
           },
           ...
         ],
         "org_repo_url": "<repo_url>",
         "org_ref_parts": [
           "<ref_type>",
           "<ref_name>",
           "<raw_id>"
         ],
         "other_ref_parts": [
           "<ref_type>",
           "<ref_name>",
           "<raw_id>"
         ],
         "comments": [
+          {
             "username": "<user_name>",
             "text": "<comment text>",
             "comment_id": "<comment_id>",
           },
           ...
         ],
         "owner": "<username>",
         "statuses": [
+          {
             "status": "<status_of_review>",        # "under_review", "approved" or "rejected"
             "reviewer": "<user_name>",
             "modified_at": "<date_time_of_review>" # iso 8601 date, server's timezone
           },
           ...
         ],
         "revisions": [
           "<raw_id>",
           ...
+        ]
     },
     error:  null
 comment_pullrequest
 ^^^^^^^^^^^^^^^^^^^
 Add comment, change status or close a given pull request. This command can only be executed
 using the api_key of a user with read permissions to the original repository.
 INPUT::
     id : <id_for_response>
     api_key : "<api_key>"
     method  : "comment_pullrequest"
     args:     {
                 "pull_request_id":  "<pull_request_id>",
                 "comment_msg":      Optional(''),
                 "status":           Optional(None),     # "under_review", "approved" or "rejected"
                 "close_pr":         Optional(False)",
+              }
 OUTPUT::
     id : <id_given_in_input>
     result: True
     error:  null
 API access for web views
 ------------------------
 API access can also be turned on for each web view in Kallithea that is
 decorated with the ``@LoginRequired`` decorator. Some views use
 ``@LoginRequired(api_access=True)`` and are always available. By default only
 RSS/Atom feed views are enabled. Other views are
 only available if they have been whitelisted. Edit the
 ``api_access_controllers_whitelist`` option in your .ini file and define views
 that should have API access enabled.
 For example, to enable API access to patch/diff, raw file and archive::
     api_access_controllers_whitelist =
         ChangesetController:changeset_patch,
         ChangesetController:changeset_raw,
         FilesController:raw,
         FilesController:archivefile
 After this change, a Kallithea view can be accessed without login using
 bearer authentication, by including this header with the request::
     Authentication: Bearer <api_key>
 Alternatively, the API key can be passed in the URL query string using
 ``?api_key=<api_key>``, though this is not recommended due to the increased
 risk of API key leaks, and support will likely be removed in the future.
 Exposing raw diffs is a good way to integrate with
 third-party services like code review, or build farms that can download archives.

docs/api/models.rst

➞

Show inline comments

@@ @@ -7,15 +7,12 @@ The :mod:`models` module @@
 .. automodule:: kallithea.model
    :members:
 .. automodule:: kallithea.model.comment
    :members:
 .. automodule:: kallithea.model.notification
    :members:
 .. automodule:: kallithea.model.permission
    :members:
 .. automodule:: kallithea.model.repo_permission
    :members:

docs/changelog.rst

➞

Show inline comments

deleted file

docs/contributing.rst

➞

Show inline comments

@@ @@ -25,68 +25,185 @@ To register, you can use your Bitbucket @@
 for more details.
 Getting started
 ---------------
 To get started with development::
+To get started with Kallithea development::
         hg clone https://kallithea-scm.org/repos/kallithea
         cd kallithea
         virtualenv ../kallithea-venv
         source ../kallithea-venv/bin/activate
         pip install --upgrade pip "setuptools<34"
         pip install -e .
         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 &
         pip install --upgrade pip setuptools
         pip install --upgrade -e .
         pip install --upgrade -r dev_requirements.txt
         kallithea-cli config-create my.ini
         kallithea-cli db-create -c my.ini --user=user --email=user@example.com --password=password --repos=/tmp
         kallithea-cli front-end-build
         gearbox serve -c my.ini --reload &
         firefox http://127.0.0.1:5000/
 You can also start out by forking https://bitbucket.org/conservancy/kallithea
 on Bitbucket_ and create a local clone of your own fork.
 If you plan to use Bitbucket_ for sending contributions, you can also fork
 Kallithea on Bitbucket_ first (https://bitbucket.org/conservancy/kallithea) and
 then replace the clone step above by a clone of your fork. In this case, please
 see :ref:`contributing-guidelines` below for configuring your fork correctly.
 Contribution flow
 -----------------
 Starting from an existing Kallithea clone, make sure it is up to date with the
 latest upstream changes::
         hg pull
         hg update
 Review the :ref:`contributing-guidelines` and :ref:`coding-guidelines`.
 If you are new to Mercurial, refer to Mercurial `Quick Start`_ and `Beginners
 Guide`_ on the Mercurial wiki.
 Now, make some changes and test them (see :ref:`contributing-tests`). Don't
 forget to add new tests to cover new functionality or bug fixes.
 For documentation changes, run ``make html`` from the ``docs`` directory to
 generate the HTML result, then review them in your browser.
 Before submitting any changes, run the cleanup script::
         ./scripts/run-all-cleanup
 When you are completely ready, you can send your changes to the community for
 review and inclusion. Most commonly used methods are sending patches to the
 mailing list (via ``hg email``) or by creating a pull request on Bitbucket_.
 .. _contributing-tests:
 Running tests
 -------------
 After finishing your changes make sure all tests pass cleanly. You can run
 the testsuite running ``nosetests`` from the project root, or if you use tox
 run ``tox`` for Python 2.6--2.7 with multiple database test.
 After finishing your changes make sure all tests pass cleanly. Run the testsuite
 by invoking ``py.test`` from the project root::
     py.test
 Note that testing on Python 2.6 also requires ``unittest2``.
 When running tests, Kallithea uses `kallithea/tests/test.ini` and populates the
 SQLite database specified there.
 Note that on unix systems, the temporary directory (``/tmp`` or where
 ``$TMPDIR`` points) must allow executable files; Git hooks must be executable,
 and the test suite creates repositories in the temporary directory. Linux
 systems with /tmp mounted noexec will thus fail.
 You can also use ``tox`` to run the tests with all supported Python versions
 (currently Python 2.6--2.7).
 When running tests, Kallithea generates a `test.ini` based on template values
 in `kallithea/tests/conftest.py` and populates the SQLite database specified
 there.
 It is possible to avoid recreating the full test database on each invocation of
 the tests, thus eliminating the initial delay. To achieve this, run the tests as::
     paster serve kallithea/tests/test.ini --pid-file=test.pid --daemon
     KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 nosetests
     gearbox serve -c /tmp/kallithea-test-XXX/test.ini --pid-file=test.pid --daemon
     KALLITHEA_WHOOSH_TEST_DISABLE=1 KALLITHEA_NO_TMP_PATH=1 py.test
     kill -9 $(cat test.pid)
 You can run individual tests by specifying their path as argument to nosetests.
 nosetests also has many more options, see `nosetests -h`. Some useful options
 In these commands, the following variables are used::
     KALLITHEA_WHOOSH_TEST_DISABLE=1 - skip whoosh index building and tests
     KALLITHEA_NO_TMP_PATH=1 - disable new temp path for tests, used mostly for testing_vcs_operations
 You can run individual tests by specifying their path as argument to py.test.
 py.test also has many more options, see `py.test -h`. Some useful options
 are::
     -x, --stop            Stop running tests after the first error or failure
     -s, --nocapture       Don't capture stdout (any stdout output will be
                           printed immediately) [NOSE_NOCAPTURE]
     --failed              Run the tests that failed in the last test run.
     -k EXPRESSION         only run tests which match the given substring
                           expression. An expression is a python evaluable
                           expression where all names are substring-matched
                           against test names and their parent classes. Example:
     -x, --exitfirst       exit instantly on first error or failed test.
     --lf                  rerun only the tests that failed at the last run (or
                           all if none failed)
     --ff                  run all tests but run the last failures first. This
                           may re-order tests and thus lead to repeated fixture
                           setup/teardown
     --pdb                 start the interactive Python debugger on errors.
     -s, --capture=no      don't capture stdout (any stdout output will be
                           printed immediately)
 Performance tests
 ^^^^^^^^^^^^^^^^^
 A number of performance tests are present in the test suite, but they are
 not run in a standard test run. These tests are useful to
 evaluate the impact of certain code changes with respect to performance.
 To run these tests::
     env TEST_PERFORMANCE=1 py.test kallithea/tests/performance
 To analyze performance, you could install pytest-profiling_, which enables the
 --profile and --profile-svg options to py.test.
 .. _pytest-profiling: https://github.com/manahl/pytest-plugins/tree/master/pytest-profiling
 .. _contributing-guidelines:
 Coding/contribution guidelines
 ------------------------------
 Contribution guidelines
 -----------------------
 Kallithea is GPLv3 and we assume all contributions are made by the
 committer/contributor and under GPLv3 unless explicitly stated. We do care a
 lot about preservation of copyright and license information for existing code
 that is brought into the project.
 Contributions will be accepted in most formats -- such as pull requests on
 Bitbucket, something hosted on your own Kallithea instance, or patches sent by
 email to the `kallithea-general`_ mailing list.
 When contributing via Bitbucket, please make your fork of
 https://bitbucket.org/conservancy/kallithea/ `non-publishing`_ -- it is one of
 the settings on "Repository details" page. This ensures your commits are in
 "draft" phase and makes it easier for you to address feedback and for project
 maintainers to integrate your changes.
 .. _non-publishing: https://www.mercurial-scm.org/wiki/Phases#Publishing_Repository
 Make sure to test your changes both manually and with the automatic tests
 before posting.
 We care about quality and review and keeping a clean repository history. We
 might give feedback that requests polishing contributions until they are
 "perfect". We might also rebase and collapse and make minor adjustments to your
 changes when we apply them.
 We try to make sure we have consensus on the direction the project is taking.
 Everything non-sensitive should be discussed in public -- preferably on the
 mailing list.  We aim at having all non-trivial changes reviewed by at least
 one other core developer before pushing. Obvious non-controversial changes will
 be handled more casually.
 There is a main development branch ("default") which is generally stable so that
 it can be (and is) used in production. There is also a "stable" branch that is
 almost exclusively reserved for bug fixes or trivial changes. Experimental
 changes should live elsewhere (for example in a pull request) until they are
 ready.
 .. _coding-guidelines:
 Coding guidelines
 -----------------
 We don't have a formal coding/formatting standard. We are currently using a mix
 of Mercurial's (https://www.mercurial-scm.org/wiki/CodingStyle), pep8, and
 consistency with existing code. Run whitespacecleanup.sh to avoid stupid
 whitespace noise in your patches.
 consistency with existing code. Run ``scripts/run-all-cleanup`` before
 committing to ensure some basic code formatting consistency.
 We support both Python 2.6.x and 2.7.x and nothing else. For now we don't care
 about Python 3 compatibility.
 We try to support the most common modern web browsers. IE9 is still supported
 to the extent it is feasible, IE8 is not.
@@ @@ -109,36 +226,72 @@ bug fixes, put ``(Issue #123)`` at the e @@
 Use American English grammar and spelling overall. Use `English title case`_ for
 page titles, button labels, headers, and 'labels' for fields in forms.
 .. _English title case: https://en.wikipedia.org/wiki/Capitalization#Title_case
 Contributions will be accepted in most formats -- such as pull requests on
 bitbucket, something hosted on your own Kallithea instance, or patches sent by
 email to the `kallithea-general`_ mailing list.
 Template helpers (that is, everything in ``kallithea.lib.helpers``)
 should only be referenced from templates. If you need to call a
 helper from the Python code, consider moving the function somewhere
 else (e.g. to the model).
 Notes on the SQLAlchemy session
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Each HTTP request runs inside an independent SQLAlchemy session (as well
 as in an independent database transaction). ``Session`` is the session manager
 and factory. ``Session()`` will create a new session on-demand or return the
 current session for the active thread. Many database operations are methods on
 such session instances - only ``Session.remove()`` should be called directly on
 the manager.
 Make sure to test your changes both manually and with the automatic tests
 before posting.
 Database model objects
 (almost) always belong to a particular SQLAlchemy session, which means
 that SQLAlchemy will ensure that they're kept in sync with the database
 (but also means that they cannot be shared across requests).
 We care about quality and review and keeping a clean repository history. We
 might give feedback that requests polishing contributions until they are
 "perfect". We might also rebase and collapse and make minor adjustments to your
 changes when we apply them.
 Objects can be added to the session using ``Session().add``, but this is
 rarely needed:
 * When creating a database object by calling the constructor directly,
   it must explicitly be added to the session.
 * When creating an object using a factory function (like
   ``create_repo``), the returned object has already (by convention)
   been added to the session, and should not be added again.
 We try to make sure we have consensus on the direction the project is taking.
 Everything non-sensitive should be discussed in public -- preferably on the
 mailing list.  We aim at having all non-trivial changes reviewed by at least
 one other core developer before pushing. Obvious non-controversial changes will
 be handled more casually.
 * When getting an object from the session (via ``Session().query`` or
   any of the utility functions that look up objects in the database),
   it's already part of the session, and should not be added again.
   SQLAlchemy monitors attribute modifications automatically for all
   objects it knows about and syncs them to the database.
 SQLAlchemy also flushes changes to the database automatically; manually
 calling ``Session().flush`` is usually only necessary when the Python
 code needs the database to assign an "auto-increment" primary key ID to
 a freshly created model object (before flushing, the ID attribute will
 be ``None``).
 TurboGears2 DebugBar
 ^^^^^^^^^^^^^^^^^^^^
 For now we just have one official branch ("default") and will keep it so stable
 that it can be (and is) used in production. Experimental changes should live
 elsewhere (for example in a pull request) until they are ready.
 It is possible to enable the TurboGears2-provided DebugBar_, a toolbar overlayed
 over the Kallithea web interface, allowing you to see:
 * timing information of the current request, including profiling information
 * request data, including GET data, POST data, cookies, headers and environment
   variables
 * a list of executed database queries, including timing and result values
 .. _translations:
 .. include:: ./../kallithea/i18n/how_to
 DebugBar is only activated when ``debug = true`` is set in the configuration
 file. This is important, because the DebugBar toolbar will be visible for all
 users, and allow them to see information they should not be allowed to see. Like
 is anyway the case for ``debug = true``, do not use this in production!
 To enable DebugBar, install ``tgext.debugbar`` and ``kajiki`` (typically via
 ``pip``) and restart Kallithea (in debug mode).
 "Roadmap"
 ---------
 We do not have a road map but are waiting for your contributions. Refer to the
@@ @@ -155,6 +308,9 @@ Thank you for your contribution! @@
 .. _pull requests: https://bitbucket.org/conservancy/kallithea/pull-requests
 .. _bitbucket: http://bitbucket.org/
 .. _mailing list: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 .. _kallithea-general: http://lists.sfconservancy.org/mailman/listinfo/kallithea-general
 .. _Hosted Weblate: https://hosted.weblate.org/projects/kallithea/kallithea/
 .. _wiki: https://bitbucket.org/conservancy/kallithea/wiki/Home
 .. _DebugBar: https://github.com/TurboGears/tgext.debugbar
 .. _Quick Start: https://www.mercurial-scm.org/wiki/QuickStart
 .. _Beginners Guide: https://www.mercurial-scm.org/wiki/BeginnersGuides

docs/dev/dbmigrations.rst

➞

Show inline comments

@@ new file 100644 @@
 =======================
 Database schema changes
 =======================
 Kallithea uses Alembic for :ref:`database migrations <upgrade_db>`
 (upgrades and downgrades).
 If you are developing a Kallithea feature that requires database schema
 changes, you should make a matching Alembic database migration script:
 . :ref:`Create a Kallithea configuration and database <setup>` for testing
    the migration script, or use existing ``development.ini`` setup.
    Ensure that this database is up to date with the latest database
    schema *before* the changes you're currently developing. (Do not
    create the database while your new schema changes are applied.)
 . Create a separate throwaway configuration for iterating on the actual
    database changes::
     kallithea-cli config-create temp.ini
    Edit the file to change database settings. SQLite is typically fine,
    but make sure to change the path to e.g. ``temp.db``, to avoid
    clobbering any existing database file.
 . Make your code changes (including database schema changes in ``db.py``).
 . After every database schema change, recreate the throwaway database
    to test the changes::
     rm temp.db
     kallithea-cli db-create -c temp.ini --repos=/var/repos --user=doe --email doe@example.com --password=123456 --no-public-access --force-yes
     kallithea-cli repo-scan -c temp.ini
 . Once satisfied with the schema changes, auto-generate a draft Alembic
    script using the development database that has *not* been upgraded.
    (The generated script will upgrade the database to match the code.)
    ::
     alembic -c development.ini revision -m "area: add cool feature" --autogenerate
 . Edit the script to clean it up and fix any problems.
    Note that for changes that simply add columns, it may be appropriate
    to not remove them in the downgrade script (and instead do nothing),
    to avoid the loss of data. Unknown columns will simply be ignored by
    Kallithea versions predating your changes.
 . Run ``alembic -c development.ini upgrade head`` to apply changes to
    the (non-throwaway) database, and test the upgrade script. Also test
    downgrades.
    The included ``development.ini`` has full SQL logging enabled. If
    you're using another configuration file, you may want to enable it
    by setting ``level = DEBUG`` in section ``[handler_console_sql]``.
 The Alembic migration script should be committed in the same revision as
 the database schema (``db.py``) changes.
 See the `Alembic documentation`__ for more information, in particular
 the tutorial and the section about auto-generating migration scripts.
 .. __: http://alembic.zzzcomputing.com/en/latest/
 Troubleshooting
 ---------------
 * If ``alembic --autogenerate`` responds "Target database is not up to
   date", you need to either first use Alembic to upgrade the database
   to the most recent version (before your changes), or recreate the
   database from scratch (without your schema changes applied).

docs/dev/translation.rst

➞

Show inline comments

		new file 100644
		.. _translations:
		.. include:: ./../../kallithea/i18n/how_to

docs/images/.img

➞

Show inline comments

deleted file

docs/index.rst

➞

Show inline comments

 .. _index:
 #######################
 Kallithea Documentation
 #######################
 **Readme**
 * :ref:`genindex`
 * :ref:`search`
 Readme
 ******
 .. toctree::
    :maxdepth: 1
    readme
 **Installation**
 Administrator guide
 *******************
 **Installation and upgrade**
 .. toctree::
    :maxdepth: 1
    overview
    installation
    installation_win
    installation_win_old
    installation_iis
    installation_puppet
    upgrade
 **Setup and configuration**
 .. toctree::
    :maxdepth: 1
    setup
    installation_puppet
    administrator_guide/auth
    administrator_guide/vcs_setup
    usage/email
    usage/customization
 **Maintenance**
 **Usage**
 .. toctree::
    :maxdepth: 1
    usage/backup
    usage/performance
    usage/debugging
    usage/troubleshooting
 User guide
 **********
 .. toctree::
    :maxdepth: 1
    usage/general
-   usage/vcs_support
+   usage/vcs_notes
    usage/locking
    usage/statistics
 **Administrator's guide**
    api/api
 .. toctree::
    :maxdepth: 1
    usage/email
    usage/performance
    usage/backup
    usage/debugging
    usage/troubleshooting
 **Development**
 Developer guide
 ***************
 .. toctree::
    :maxdepth: 1
    contributing
    changelog
 **API**
 .. toctree::
    :maxdepth: 1
    api/api
    api/models
 Other topics
 ------------
 * :ref:`genindex`
 * :ref:`search`
    dev/translation
    dev/dbmigrations
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _python: http://www.python.org/
 .. _django: http://www.djangoproject.com/
 .. _mercurial: https://www.mercurial-scm.org/

docs/installation.rst

➞

Show inline comments

@@ @@ -23,34 +23,47 @@ The following describes three different @@
   a Kallithea release is using standard pip. The package will be installed in
   the same location as all other Python packages you have ever installed. As a
   result, removing it is not as straightforward as with a virtualenv, as you'd
   have to remove its dependencies manually and make sure that they are not
   needed by other packages.
 Regardless of the installation method you may need to make sure you have
 appropriate development packages installed, as installation of some of the
 Kallithea dependencies requires a working C compiler and libffi library
 headers. Depending on your configuration, you may also need to install
 Git and development packages for the database of your choice.
 For Debian and Ubuntu, the following command will ensure that a reasonable
 set of dependencies is installed::
     sudo apt-get install build-essential git python-pip python-virtualenv libffi-dev python-dev
 For Fedora and RHEL-derivatives, the following command will ensure that a
 reasonable set of dependencies is installed::
     sudo yum install gcc git python-pip python-virtualenv libffi-devel python-devel
 .. _installation-source:
 Installation from repository source
 -----------------------------------
 To install Kallithea in a virtualenv_ using the stable branch of the development
 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
         pip install --upgrade pip "setuptools<34"
         pip install -e .
         . ../kallithea-venv/bin/activate
         pip install --upgrade pip setuptools
         pip install --upgrade -e .
         python2 setup.py compile_catalog   # for translation of the UI
 You can now proceed to :ref:`setup`.
 To upgrade, simply update the repository with ``hg pull -u`` and restart the
 server.
 .. _installation-virtualenv:
 Installing a released version in a virtualenv
 ---------------------------------------------
@@ @@ -65,44 +78,44 @@ An additional benefit of virtualenv_ is @@
     virtualenv /srv/kallithea/venv
 - Activate the virtualenv_ in your current shell session and make sure the
   basic requirements are up-to-date by running::
     source /srv/kallithea/venv/bin/activate
     pip install --upgrade pip "setuptools<34"
     . /srv/kallithea/venv/bin/activate
     pip install --upgrade pip setuptools
 .. 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.
 .. note:: Some dependencies are optional. If you need them, install them in
    the virtualenv too::
      pip install psycopg2
      pip install python-ldap
      pip install --upgrade psycopg2
      pip install --upgrade python-ldap
    This might require installation of development packages using your
    distribution's package manager.
 - 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
+    pip install --upgrade kallithea
   Alternatively, download a .tar.gz from http://pypi.python.org/pypi/Kallithea,
   extract it and run::
     pip install .
+    pip install --upgrade .
 - This will install Kallithea together with pylons_ and all other required
   python libraries into the activated virtualenv.
 - This will install Kallithea together with all other required
   Python libraries into the activated virtualenv.
 You can now proceed to :ref:`setup`.
 .. _installation-without-virtualenv:
@@ @@ -120,93 +133,7 @@ To install as a regular user in ``~/.loc @@
     pip install --user kallithea
 You can now proceed to :ref:`setup`.
 Upgrading Kallithea from Python Package Index (PyPI)
 ----------------------------------------------------
 .. note::
    It is strongly recommended that you **always** perform a database and
    configuration backup before doing an upgrade.
    These directions will use '{version}' to note that this is the version of
    Kallithea that these files were used with.  If backing up your Kallithea
    instance from version 0.1 to 0.2, the ``my.ini`` file could be
    backed up to ``my.ini.0-1``.
 If using a SQLite database, stop the Kallithea process/daemon/service, and
 then make a copy of the database file::
  service kallithea stop
  cp kallithea.db kallithea.db.{version}
 Back up your configuration file::
  cp my.ini my.ini.{version}
 Ensure that you are using the Python virtual environment that you originally
 installed Kallithea in by running::
  pip freeze
 This will list all packages installed in the current environment.  If
 Kallithea isn't listed, activate the correct virtual environment::
  source /srv/kallithea/venv/bin/activate
 Once you have verified the environment you can upgrade Kallithea with::
  pip install --upgrade kallithea
 Then run the following command from the installation directory::
  paster make-config Kallithea my.ini
 This will display any changes made by the new version of Kallithea to your
 current configuration. It will try to perform an automerge. It is recommended
 that you recheck the content after the automerge.
 .. note::
    Please always make sure your .ini files are up to date. Errors can
    often be caused by missing parameters added in new versions.
 It is also recommended that you rebuild the whoosh index after upgrading since
 the new whoosh version could introduce some incompatible index changes. Please
 read the changelog to see if there were any changes to whoosh.
 The final step is to upgrade the database. To do this simply run::
  paster upgrade-db my.ini
 This will upgrade the schema and update some of the defaults in the database,
 and will always recheck the settings of the application, if there are no new
 options that need to be set.
 .. note::
    The DB schema upgrade library has some limitations and can sometimes fail if you try to
    upgrade from older major releases. In such a case simply run upgrades sequentially, e.g.,
    upgrading from 0.1.X to 0.3.X should be done like this: 0.1.X. > 0.2.X > 0.3.X
    You can always specify what version of Kallithea you want to install for example in pip
    `pip install Kallithea==0.2`
 You may find it helpful to clear out your log file so that new errors are
 readily apparent::
  echo > kallithea.log
 Once that is complete, you may now start your upgraded Kallithea Instance::
  service kallithea start
 Or::
  paster serve /srv/kallithea/my.ini
 .. note::
    If you're using Celery, make sure you restart all instances of it after
    upgrade.
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _pylons: http://www.pylonsproject.org/

docs/installation_iis.rst

➞

Show inline comments

@@ @@ -36,13 +36,13 @@ Installation @@
 The following assumes that your Kallithea is at ``c:\inetpub\kallithea``, and
 will be served from the root of its own website. The changes to serve it in its
 own virtual folder will be noted where appropriate.
 Application pool
-................
+^^^^^^^^^^^^^^^^
 Make sure that there is a unique application pool for the Kallithea application
 with an identity that has read access to the Kallithea distribution.
 The application pool does not need to be able to run any managed code. If you
 are using a 32-bit Python installation, then you must enable 32-bit program in
@@ @@ -52,17 +52,17 @@ to run on the website and neither will K @@
 .. note::
     The application pool can be the same as an existing application pool,
     as long as the Kallithea requirements are met by the existing pool.
 ISAPI handler
-.............
+^^^^^^^^^^^^^
 The ISAPI handler can be generated using::
-    paster install-iis my.ini --virtualdir=/
+    kallithea-cli iis-install -c my.ini --virtualdir=/
 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::
@@ @@ -71,18 +71,18 @@ 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
 ``--virtualdir`` specified above pointing to ``_dispatch.dll``.
 The ISAPI handler is registered to all file extensions, so it will automatically
 be the one handling all requests to the specified virtual directory. When the website starts
-the ISAPI handler, it will start a thread pool managed wrapper around the paster
 the ISAPI handler, it will start a thread pool managed wrapper around the
 middleware WSGI handler that Kallithea runs within and each HTTP request to the
 site will be processed through this logic henceforth.
 Authentication with Kallithea using IIS authentication modules
-..............................................................
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The recommended way to handle authentication with Kallithea using IIS is to let
 IIS handle all the authentication and just pass it to Kallithea.
 .. note::
@@ @@ -108,13 +108,13 @@ Windows authentication. @@
 Troubleshooting
 ---------------
 Typically, any issues in this setup will either be entirely in IIS or entirely
-in Kallithea (or Kallithea's WSGI/paster middleware). Consequently, two
 in Kallithea (or Kallithea's WSGI middleware). Consequently, two
 different options for finding issues exist: IIS' failed request tracking which
 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::

docs/installation_puppet.rst

➞

Show inline comments

@@ @@ -87,13 +87,13 @@ Using parameters for customizing the set @@
 The ``kallithea`` Puppet class provides a number of `parameters
 <https://forge.puppetlabs.com/rauch/kallithea#class-kallithea>`_ for
 customizing the setup process. You have seen the usage of the ``seed_db``
 parameter in the :ref:`example above <simple_manifest>`, but there are more.
 For example, you can specify the installation directory, the name of the user
 under which Kallithea gets installed, the initial admin password, etc.
-Notably, you can provide arbitrary modifications to Kallitheas configuration
+Notably, you can provide arbitrary modifications to Kallithea's configuration
 file by means of the ``config_hash`` parameter.
 Parameters, which have not been set explicitly, will be set to default values,
 which are defined inside the ``kallithea`` Puppet module. For example, if you
 just stick to the defaults as in the :ref:`example above <simple_manifest>`,
 you will end up with a Kallithea instance, which

docs/installation_win.rst

➞

Show inline comments

 .. _installation_win:
 ================================================================
 Installation and upgrade on Windows (7/Server 2008 R2 and newer)
 ================================================================
 ====================================================
 Installation on Windows (7/Server 2008 R2 and newer)
 ====================================================
 First time install
-::::::::::::::::::
+------------------
 Target OS: Windows 7 and newer or Windows Server 2008 R2 and newer
 Tested on Windows 8.1, Windows Server 2008 R2 and Windows Server 2012
 To install on an older version of Windows, see `<installation_win_old.html>`_
 Step 1 -- Install Python
-------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^
 Install Python 2.x.y (x = 6 or 7). Latest version is recommended. If you need another version, they can run side by side.
 .. warning:: Python 3.x is not supported.
 - Download Python 2.x.y from http://www.python.org/download/
@@ @@ -28,13 +28,13 @@ Install Python 2.x.y (x = 6 or 7). Lates @@
 While writing this guide, the latest version was v2.7.9.
 Remember the specific major and minor versions installed, because they will
 be needed in the next step. In this case, it is "2.7".
 Step 2 -- Python BIN
---------------------
+^^^^^^^^^^^^^^^^^^^^
 Add Python BIN folder to the path. This can be done manually (editing
 "PATH" environment variable) or by using Windows Support Tools that
 come pre-installed in Windows Vista/7 and later.
 Open a CMD and type::
@@ @@ -42,13 +42,13 @@ Open a CMD and type:: @@
   SETX PATH "%PATH%;[your-python-path]" /M
 Please substitute [your-python-path] with your Python installation
 path. Typically this is ``C:\\Python27``.
 Step 3 -- Install pywin32 extensions
-------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Download pywin32 from:
 http://sourceforge.net/projects/pywin32/files/
 - Click on "pywin32" folder
 - Click on the first folder (in this case, Build 219, maybe newer when you try)
@@ @@ -58,13 +58,13 @@ http://sourceforge.net/projects/pywin32/ @@
   http://sourceforge.net/projects/pywin32/files/pywin32/Build%20219/pywin32-219.win-amd64-py2.7.exe/download
   (x64)
   http://sourceforge.net/projects/pywin32/files/pywin32/Build%20219/pywin32-219.win32-py2.7.exe/download
   (Win32)
 Step 4 -- Install pip
----------------------
+^^^^^^^^^^^^^^^^^^^^^
 pip is a package management system for Python. You will need it to install Kallithea and its dependencies.
 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:
@@ @@ -82,13 +82,13 @@ Note that pip.exe will be placed inside @@
 Scripts folder, which is likely not on your path. To correct this,
 open a CMD and type::
   SETX PATH "%PATH%;[your-python-path]\Scripts" /M
 Step 5 -- Kallithea folder structure
-------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Create a Kallithea folder structure.
 This is only an example to install Kallithea. Of course, you can
 change it. However, this guide will follow the proposed structure, so
 please later adapt the paths if you change them. Folders without
@@ @@ -99,13 +99,13 @@ Create the following folder structure:: @@
   C:\Kallithea
   C:\Kallithea\Bin
   C:\Kallithea\Env
   C:\Kallithea\Repos
 Step 6 -- Install virtualenv
-----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 .. note::
    A python virtual environment will allow for isolation between the Python packages of your system and those used for Kallithea.
    It is strongly recommended to use it to ensure that Kallithea does not change a dependency that other software uses or vice versa.
 In a command prompt type::
@@ @@ -116,13 +116,13 @@ Virtualenv will now be inside your Pytho @@
 To create a virtual environment, run::
   virtualenv C:\Kallithea\Env
 Step 7 -- Install Kallithea
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In order to install Kallithea, you need to be able to run "pip install kallithea". It will use pip to install the Kallithea Python package and its dependencies.
 Some Python packages use managed code and need to be compiled.
 This can be done on Linux without any special steps. On Windows, you will need to install Microsoft Visual C++ compiler for Python 2.7.
 Download and install "Microsoft Visual C++ Compiler for Python 2.7" from http://aka.ms/vcpython27
@@ @@ -131,77 +131,79 @@ Download and install "Microsoft Visual C @@
   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
-  pip install --upgrade pip "setuptools<34"
   pip install --upgrade pip setuptools
 The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar
 (depending of your folder structure). Then type::
   pip install kallithea
 .. note:: This will take some time. Please wait patiently until it is fully
           complete. Some warnings will appear. Don't worry, they are
           normal.
 Step 8 -- Install git (optional)
 --------------------------------
 Step 8 -- Install Git (optional)
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Mercurial being a python package, was installed automatically when doing ``pip install kallithea``.
 Mercurial being a python package, it was installed automatically when doing "pip install kallithea".
 You need to install git manually if you want Kallithea to be able to host git repositories.
 You need to install Git manually if you want Kallithea to be able to host Git repositories.
 See http://git-scm.com/book/en/v2/Getting-Started-Installing-Git#Installing-on-Windows for instructions.
 The location of the Git binaries (like ``c:\path\to\git\bin``) must be
 added to the ``PATH`` environment variable so ``git.exe`` and other tools like
 ``gzip.exe`` are available.
 Step 9 -- Configuring Kallithea
--------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Steps taken from `<setup.html>`_
 You have to use the same command prompt as in Step 7, so if you closed
 it, reopen it following the same commands (including the "activate"
 one). When ready, type::
   cd C:\Kallithea\Bin
-  paster make-config Kallithea production.ini
+  kallithea-cli config-create my.ini
-Then you must edit production.ini to fit your needs (IP address, IP
+Then you must edit my.ini to fit your needs (IP address, IP
 port, mail settings, database, etc.). `NotePad++`__ or a similar text
 editor is recommended to properly handle the newline character
 differences between Unix and Windows.
 __ http://notepad-plus-plus.org/
 For the sake of simplicity, run it with the default settings. After your edits (if any) in the previous command prompt, type::
-  paster setup-db production.ini
+  kallithea-cli db-create -c my.ini
 .. warning:: This time a *new* database will be installed. You must
              follow a different step to later *upgrade* to a newer
              Kallithea version)
              follow a different process to later :ref:`upgrade <upgrade>`
              to a newer Kallithea version.
 The script will ask you for confirmation about creating a new database, answer yes (y)
 The script will ask you for the repository path, answer C:\\Kallithea\\Repos (or similar).
 The script will ask you for the admin username and password, answer "admin" + "123456" (or whatever you want)
 The script will ask you for admin mail, answer "admin@xxxx.com" (or whatever you want).
 If you make a mistake and the script doesn't end, don't worry: start it again.
-If you decided not to install git, you will get errors about it that you can ignore.
+If you decided not to install Git, you will get errors about it that you can ignore.
 Step 10 -- Running Kallithea
-----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In the previous command prompt, being in the C:\\Kallithea\\Bin folder, type::
-  paster serve production.ini
+  gearbox serve -c my.ini
 Open your web server, and go to http://127.0.0.1:5000
 It works!! :-)
 Remark:
@@ @@ -216,30 +218,6 @@ What this guide does not cover: @@
   - http://ryrobes.com/python/running-python-scripts-as-a-windows-service/
   - http://wiki.pylonshq.com/display/pylonscookbook/How+to+run+Pylons+as+a+Windows+service
 - Using Apache. You can investigate here:
   - https://groups.google.com/group/rhodecode/msg/c433074e813ffdc4
 Upgrading
 :::::::::
 Stop running Kallithea
 Open a CommandPrompt like in Step 7 (cd to C:\Kallithea\Env\Scripts and activate) and type::
   pip install kallithea --upgrade
   cd \Kallithea\Bin
 Backup your production.ini file now.
 Then run::
   paster make-config Kallithea production.ini
 Look for changes and update your production.ini accordingly.
 Next, update the database::
   paster upgrade-db production.ini
 More details can be found in `<upgrade.html>`_.

docs/installation_win_old.rst

➞

Show inline comments

 .. _installation_win_old:
 ======================================================================
 Installation and upgrade on Windows (XP/Vista/Server 2003/Server 2008)
 ======================================================================
 ==========================================================
 Installation on Windows (XP/Vista/Server 2003/Server 2008)
 ==========================================================
 First-time install
-::::::::::::::::::
+------------------
 Target OS: Windows XP SP3 32-bit English (Clean installation)
 + All Windows Updates until 24-may-2012
 .. note::
@@ @@ -21,13 +21,13 @@ Target OS: Windows XP SP3 32-bit English @@
    If you run into any 64-bit related problems, please check these pages:
    - http://blog.victorjabur.com/2011/06/05/compiling-python-2-7-modules-on-windows-32-and-64-using-msvc-2008-express/
    - http://bugs.python.org/issue7511
 Step 1 -- Install Visual Studio 2008 Express
---------------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Optional: You can also install MinGW, but VS2008 installation is easier.
 Download "Visual C++ 2008 Express Edition with SP1" from:
 http://download.microsoft.com/download/E/8/E/E8EEB394-7F42-4963-A2D8-29559B738298/VS2008ExpressWithSP1ENUX1504728.iso
 (if not found or relocated, google for "visual studio 2008 express" for updated link. This link was taken from http://stackoverflow.com/questions/15318560/visual-c-2008-express-download-link-dead)
@@ @@ -55,13 +55,13 @@ choose "Visual C++ 2008 Express" when in @@
 -bit: You also need to copy and rename a .bat file to make the Visual C++ compiler work.
    I am not sure why this is not necessary for 32-bit.
    Copy C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\vcvars64.bat to C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\amd64\vcvarsamd64.bat
 Step 2 -- Install Python
-------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^
 Install Python 2.x.y (x = 6 or 7) x86 version (32-bit). DO NOT USE A 3.x version.
 Download Python 2.x.y from:
 http://www.python.org/download/
 Choose "Windows Installer" (32-bit version) not "Windows X86-64
@@ @@ -71,13 +71,13 @@ be needed in the next step. In this case @@
 .. note::
 -bit: Just download and install the 64-bit version of python.
 Step 3 -- Install Win32py extensions
-------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Download pywin32 from:
 http://sourceforge.net/projects/pywin32/files/
 - Click on "pywin32" folder
 - Click on the first folder (in this case, Build 217, maybe newer when you try)
@@ @@ -90,13 +90,13 @@ http://sourceforge.net/projects/pywin32/ @@
 -bit: Download and install the 64-bit version.
      At the time of writing you can find this at:
      http://sourceforge.net/projects/pywin32/files/pywin32/Build%20218/pywin32-218.win-amd64-py2.7.exe/download
 Step 4 -- Python BIN
---------------------
+^^^^^^^^^^^^^^^^^^^^
 Add Python BIN folder to the path
 You have to add the Python folder to the path, you can do it manually
 (editing "PATH" environment variable) or using Windows Support Tools
 that came preinstalled in Vista/7 and can be installed in Windows XP.
@@ @@ -117,13 +117,13 @@ that came preinstalled in Vista/7 and ca @@
     SETX PATH "%PATH%;[your-python-path]" /M
   Please substitute [your-python-path] with your Python installation path.
   Typically: C:\\Python27
 Step 5 -- Kallithea folder structure
-------------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Create a Kallithea folder structure
 This is only a example to install Kallithea, you can of course change
 it. However, this guide will follow the proposed structure, so please
 later adapt the paths if you change them. My recommendation is to use
@@ @@ -134,13 +134,13 @@ Create the following folder structure:: @@
   C:\Kallithea
   C:\Kallithea\Bin
   C:\Kallithea\Env
   C:\Kallithea\Repos
 Step 6 -- Install virtualenv
-----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Install Virtual Env for Python
 Navigate to: http://www.virtualenv.org/en/latest/index.html#installation
 Right click on "virtualenv.py" file and choose "Save link as...".
 Download to C:\\Kallithea (or whatever you want)
@@ @@ -154,13 +154,13 @@ where you downloaded "virtualenv.py", an @@
   python2 virtualenv.py C:\Kallithea\Env
 (--no-site-packages is now the default behaviour of virtualenv, no need
 to include it)
 Step 7 -- Install Kallithea
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Finally, install Kallithea
 Close previously opened command prompt/s, and open a Visual Studio 2008
 Command Prompt (**IMPORTANT!!**). To do so, go to Start Menu, and then open
 "Microsoft Visual C++ 2008 Express Edition" -> "Visual Studio Tools" ->
@@ @@ -180,48 +180,49 @@ to:: @@
 %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
-  pip install --upgrade pip "setuptools<34"
   pip install --upgrade pip setuptools
 The prompt will change into "(Env) C:\\Kallithea\\Env\\Scripts" or similar
 (depending of your folder structure). Then type::
  pip install kallithea
 (long step, please wait until fully complete)
 Some warnings will appear, don't worry as they are normal.
 Step 8 -- Configuring Kallithea
--------------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 steps taken from http://packages.python.org/Kallithea/setup.html
 You have to use the same Visual Studio 2008 command prompt as Step7, so
 if you closed it reopen it following the same commands (including the
 "activate" one). When ready, just type::
   cd C:\Kallithea\Bin
-  paster make-config Kallithea production.ini
+  kallithea-cli config-create my.ini
-Then, you must edit production.ini to fit your needs (network address and
+Then, you must edit my.ini to fit your needs (network address and
 port, mail settings, database, whatever). I recommend using NotePad++
 (free) or similar text editor, as it handles well the EndOfLine
 character differences between Unix and Windows
 (http://notepad-plus-plus.org/)
 For the sake of simplicity lets run it with the default settings. After
 your edits (if any), in the previous Command Prompt, type::
- paster setup-db production.ini
+  kallithea-cli db-create -c my.ini
 (this time a NEW database will be installed, you must follow a different
 step to later UPGRADE to a newer Kallithea version)
 .. warning:: This time a *new* database will be installed. You must
              follow a different process to later :ref:`upgrade <upgrade>`
              to a newer Kallithea version.
 The script will ask you for confirmation about creating a NEW database,
 answer yes (y)
 The script will ask you for repository path, answer C:\\Kallithea\\Repos
 (or similar)
 The script will ask you for admin username and password, answer "admin"
@@ @@ -230,18 +231,18 @@ The script will ask you for admin mail, @@
 whatever you want)
 If you make some mistake and the script does not end, don't worry, start
 it again.
 Step 9 -- Running Kallithea
----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
 In the previous command prompt, being in the C:\\Kallithea\\Bin folder,
 just type::
- paster serve production.ini
+ gearbox serve -c my.ini
 Open yout web server, and go to http://127.0.0.1:5000
 It works!! :-)
 Remark:
@@ @@ -257,26 +258,6 @@ What this Guide does not cover: @@
   - http://ryrobes.com/python/running-python-scripts-as-a-windows-service/
   - http://wiki.pylonshq.com/display/pylonscookbook/How+to+run+Pylons+as+a+Windows+service
 - Using Apache. You can investigate here:
   - https://groups.google.com/group/rhodecode/msg/c433074e813ffdc4
 Upgrading
 :::::::::
 Stop running Kallithea
 Open a CommandPrompt like in Step7 (VS2008 path + activate) and type::
  easy_install -U kallithea
  cd \Kallithea\Bin
 { backup your production.ini file now} ::
  paster make-config Kallithea production.ini
 (check changes and update your production.ini accordingly) ::
  paster upgrade-db production.ini (update database)
 Full steps in http://packages.python.org/Kallithea/upgrade.html

docs/make.bat

➞

Show inline comments

 @ECHO OFF
 REM Command file for Sphinx documentation
 if "%SPHINXBUILD%" == "" (
-	set SPHINXBUILD=sphinx-build
+    set SPHINXBUILD=sphinx-build
+)
 set BUILDDIR=_build
 set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
 if NOT "%PAPER%" == "" (
-	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+    set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+)
 if "%1" == "" goto help
 if "%1" == "help" (
 	:help
 	echo.Please use `make ^<target^>` where ^<target^> is one of
 	echo.  html       to make standalone HTML files
 	echo.  dirhtml    to make HTML files named index.html in directories
 	echo.  singlehtml to make a single large HTML file
 	echo.  pickle     to make pickle files
 	echo.  json       to make JSON files
 	echo.  htmlhelp   to make HTML files and a HTML help project
 	echo.  qthelp     to make HTML files and a qthelp project
 	echo.  devhelp    to make HTML files and a Devhelp project
 	echo.  epub       to make an epub
 	echo.  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter
 	echo.  text       to make text files
 	echo.  man        to make manual pages
 	echo.  changes    to make an overview over all changed/added/deprecated items
 	echo.  linkcheck  to check all external links for integrity
 	echo.  doctest    to run all doctests embedded in the documentation if enabled
 	goto end
     :help
     echo.Please use `make ^<target^>` where ^<target^> is one of
     echo.  html       to make standalone HTML files
     echo.  dirhtml    to make HTML files named index.html in directories
     echo.  singlehtml to make a single large HTML file
     echo.  pickle     to make pickle files
     echo.  json       to make JSON files
     echo.  htmlhelp   to make HTML files and a HTML help project
     echo.  qthelp     to make HTML files and a qthelp project
     echo.  devhelp    to make HTML files and a Devhelp project
     echo.  epub       to make an epub
     echo.  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter
     echo.  text       to make text files
     echo.  man        to make manual pages
     echo.  changes    to make an overview over all changed/added/deprecated items
     echo.  linkcheck  to check all external links for integrity
     echo.  doctest    to run all doctests embedded in the documentation if enabled
     goto end
+)
 if "%1" == "clean" (
 	for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
 	del /q /s %BUILDDIR%\*
 	goto end
     for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
     del /q /s %BUILDDIR%\*
     goto end
+)
 if "%1" == "html" (
 	%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
 	echo.
 	echo.Build finished. The HTML pages are in %BUILDDIR%/html.
 	goto end
     %SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
     echo.
     echo.Build finished. The HTML pages are in %BUILDDIR%/html.
     goto end
+)
 if "%1" == "dirhtml" (
 	%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
 	echo.
 	echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
 	goto end
     %SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
     echo.
     echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
     goto end
+)
 if "%1" == "singlehtml" (
 	%SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
 	echo.
 	echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
 	goto end
     %SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
     echo.
     echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
     goto end
+)
 if "%1" == "pickle" (
 	%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
 	echo.
 	echo.Build finished; now you can process the pickle files.
 	goto end
     %SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
     echo.
     echo.Build finished; now you can process the pickle files.
     goto end
+)
 if "%1" == "json" (
 	%SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
 	echo.
 	echo.Build finished; now you can process the JSON files.
 	goto end
     %SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
     echo.
     echo.Build finished; now you can process the JSON files.
     goto end
+)
 if "%1" == "htmlhelp" (
 	%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
 	echo.
 	echo.Build finished; now you can run HTML Help Workshop with the ^
     %SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
     echo.
     echo.Build finished; now you can run HTML Help Workshop with the ^
 .hhp project file in %BUILDDIR%/htmlhelp.
-	goto end
+    goto end
+)
 if "%1" == "qthelp" (
 	%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
 	echo.
 	echo.Build finished; now you can run "qcollectiongenerator" with the ^
     %SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
     echo.
     echo.Build finished; now you can run "qcollectiongenerator" with the ^
 .qhcp project file in %BUILDDIR%/qthelp, like this:
 	echo.^> qcollectiongenerator %BUILDDIR%\qthelp\Kallithea.qhcp
 	echo.To view the help file:
 	echo.^> assistant -collectionFile %BUILDDIR%\qthelp\Kallithea.ghc
 	goto end
     echo.^> qcollectiongenerator %BUILDDIR%\qthelp\Kallithea.qhcp
     echo.To view the help file:
     echo.^> assistant -collectionFile %BUILDDIR%\qthelp\Kallithea.ghc
     goto end
+)
 if "%1" == "devhelp" (
 	%SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
 	echo.
 	echo.Build finished.
 	goto end
     %SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
     echo.
     echo.Build finished.
     goto end
+)
 if "%1" == "epub" (
 	%SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
 	echo.
 	echo.Build finished. The epub file is in %BUILDDIR%/epub.
 	goto end
     %SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
     echo.
     echo.Build finished. The epub file is in %BUILDDIR%/epub.
     goto end
+)
 if "%1" == "latex" (
 	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
 	echo.
 	echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
 	goto end
     %SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
     echo.
     echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
     goto end
+)
 if "%1" == "text" (
 	%SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
 	echo.
 	echo.Build finished. The text files are in %BUILDDIR%/text.
 	goto end
     %SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
     echo.
     echo.Build finished. The text files are in %BUILDDIR%/text.
     goto end
+)
 if "%1" == "man" (
 	%SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
 	echo.
 	echo.Build finished. The manual pages are in %BUILDDIR%/man.
 	goto end
     %SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
     echo.
     echo.Build finished. The manual pages are in %BUILDDIR%/man.
     goto end
+)
 if "%1" == "changes" (
 	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
 	echo.
 	echo.The overview file is in %BUILDDIR%/changes.
 	goto end
     %SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
     echo.
     echo.The overview file is in %BUILDDIR%/changes.
     goto end
+)
 if "%1" == "linkcheck" (
 	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
 	echo.
 	echo.Link check complete; look for any errors in the above output ^
     %SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
     echo.
     echo.Link check complete; look for any errors in the above output ^
 or in %BUILDDIR%/linkcheck/output.txt.
-	goto end
+    goto end
+)
 if "%1" == "doctest" (
 	%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
 	echo.
 	echo.Testing of doctests in the sources finished, look at the ^
     %SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
     echo.
     echo.Testing of doctests in the sources finished, look at the ^
 results in %BUILDDIR%/doctest/output.txt.
-	goto end
+    goto end
+)
 :end

docs/overview.rst

➞

Show inline comments

@@ @@ -66,12 +66,17 @@ installed. @@
   other package, usually as a ``.../site-packages/Kallithea-X-py2.7.egg/``
   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::
    Kallithea includes front-end code that needs to be processed first.
    The tool npm_ is used to download external dependencies and orchestrate the
    processing. The ``npm`` binary must thus be available.
 Web server
 ----------
 Kallithea is (primarily) a WSGI_ application that must be run from a web
 server that serves WSGI applications over HTTP.
@@ @@ -81,23 +86,23 @@ responsibility. Kallithea does however n @@
 (protocol, address, port and path) for each HTTP request. Kallithea will
 usually use its own HTML/cookie based authentication but can also be configured
 to use web server authentication.
 There are several web server options:
 - Kallithea uses the Paste_ tool as command line interface. Paste provides
   ``paster serve`` as a convenient way to launch a Python WSGI / web server
 - 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.
-  Paste comes with its own built-in web server but Kallithea defaults to use
+  Gearbox comes with its own built-in web server but Kallithea defaults to use
   Waitress_. Gunicorn_ is also an option. These web servers have different
   limited feature sets.
-  The web server used by ``paster`` is configured in the ``.ini`` file passed
+  The web server used by ``gearbox`` is configured in the ``.ini`` file passed
   to it. The entry point for the WSGI application is configured
   in ``setup.py`` as ``kallithea.config.middleware:make_app``.
 - `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.
@@ @@ -110,32 +115,32 @@ There are several web server options: @@
   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
   option, for example to standardize on one internet-facing web server, to add
   encryption or special authentication or for other security reasons, to
   provide caching of static files, or to provide load balancing or fail-over.
   Nginx_, Varnish_ and HAProxy_ are often used for this purpose, often in front
-  of a ``paster`` server that somehow is wrapped as a service.
+  of a ``gearbox serve`` that somehow is wrapped as a service.
 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/
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
-.. _Paste: http://pythonpaste.org/
+.. _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
 .. _uWSGI: https://uwsgi-docs.readthedocs.org/en/latest/
 .. _nginx: http://nginx.org/en/
 .. _iis: http://en.wikipedia.org/wiki/Internet_Information_Services
 .. _pip: http://en.wikipedia.org/wiki/Pip_%28package_manager%29
 .. _WSGI: http://en.wikipedia.org/wiki/Web_Server_Gateway_Interface
 .. _pylons: http://www.pylonsproject.org/
 .. _HAProxy: http://www.haproxy.org/
 .. _Varnish: https://www.varnish-cache.org/
 .. _npm: https://www.npmjs.com/

docs/setup.rst

➞

Show inline comments

@@ @@ -8,40 +8,42 @@ Setup @@
 Setting up Kallithea
 --------------------
 First, you will need to create a Kallithea configuration file. Run the
 following command to do so::
-    paster make-config Kallithea my.ini
+    kallithea-cli config-create my.ini
 This will create the file ``my.ini`` in the current directory. This
 configuration file contains the various settings for Kallithea, e.g.
 proxy port, email settings, usage of static files, cache, Celery
 settings, and logging.
 settings, and logging. Extra settings can be specified like::
     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
 PostgreSQL, SQLite and MySQL databases. Create the database by running
 the following command::
-    paster setup-db my.ini
+    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
 entering this "root" path ``setup-db`` will also prompt you for a username
 and password for the initial admin account which ``setup-db`` sets
 entering this "root" path ``db-create`` will also prompt you for a username
 and password for the initial admin account which ``db-create`` sets
 up for you.
-The ``setup-db`` values can also be given on the command line.
+The ``db-create`` values can also be given on the command line.
 Example::
-    paster setup-db my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos
+    kallithea-cli db-create -c my.ini --user=nn --password=secret --email=nn@example.com --repos=/srv/repos
-The ``setup-db`` command will create all needed tables and an
+The ``db-create`` 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
 location to its database.  (Note: make sure you specify the correct
 path to the root).
@@ @@ -49,43 +51,45 @@ path to the root). @@
 .. 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.
 Finally, prepare the front-end by running::
     kallithea-cli front-end-build
 You are now ready to use Kallithea. To run it simply execute::
-    paster serve my.ini
+    gearbox serve -c my.ini
 - This command runs the Kallithea server. The web app should be available at
   http://127.0.0.1:5000. The IP address and port is configurable via the
   configuration file created in the previous step.
-- Log in to Kallithea using the admin account created when running ``setup-db``.
+- Log in to Kallithea using the admin account created when running ``db-create``.
 - The default permissions on each repository is read, and the owner is admin.
   Remember to update these if needed.
 - In the admin panel you can toggle LDAP, anonymous, and permissions
   settings, as well as edit more advanced options on users and
   repositories.
 Extensions
 ----------
 Optionally one can create an ``rcextensions`` package that extends Kallithea
 functionality.
 To generate a skeleton extensions package, run::
 Internationalization (i18n support)
 -----------------------------------
     paster make-rcext my.ini
 The Kallithea web interface is automatically displayed in the user's preferred
 language, as indicated by the browser. Thus, different users may see the
 application in different languages. If the requested language is not available
 (because the translation file for that language does not yet exist or is
 incomplete), the language specified in setting ``i18n.lang`` in the Kallithea
 configuration file is used as fallback. If no fallback language is explicitly
 specified, English is used.
 This will create an ``rcextensions`` package next to the specified ``ini`` file.
 With ``rcextensions`` it's possible to add additional mapping for whoosh,
 stats and add additional code into the push/pull/create/delete repo hooks,
 for example for sending signals to build-bots such as Jenkins.
 See the ``__init__.py`` file inside the generated ``rcextensions`` package
 for more details.
 If you want to disable automatic language detection and instead configure a
 fixed language regardless of user preference, set ``i18n.enabled = false`` and
 set ``i18n.lang`` to the desired language (or leave empty for English).
 Using Kallithea with SSH
 ------------------------
 Kallithea currently only hosts repositories using http and https. (The addition
@@ @@ -126,361 +130,118 @@ Setting up Whoosh full text search @@
 Kallithea provides full text search of repositories using `Whoosh`__.
 .. __: https://whoosh.readthedocs.io/en/latest/
 For an incremental index build, run::
-    paster make-index my.ini
+    kallithea-cli index-create -c my.ini
 For a full index rebuild, run::
-    paster make-index my.ini -f
+    kallithea-cli index-create -c my.ini --full
-The ``--repo-location`` option allows the location of the repositories to be overriden;
+The ``--repo-location`` option allows the location of the repositories to be overridden;
 usually, the location is retrieved from the Kallithea database.
 The ``--index-only`` option can be used to limit the indexed repositories to a comma-separated list::
-    paster make-index my.ini --index-only=vcs,kallithea
+    kallithea-cli index-create -c my.ini --index-only=vcs,kallithea
 To keep your index up-to-date it is necessary to do periodic index builds;
 for this, it is recommended to use a crontab entry. Example::
-3  *  *  *  /path/to/virtualenv/bin/paster make-index /path/to/kallithea/my.ini
+3  *  *  *  /path/to/virtualenv/bin/kallithea-cli index-create -c /path/to/kallithea/my.ini
 When using incremental mode (the default), Whoosh will check the last
 modification date of each file and add it to be reindexed if a newer file is
 available. The indexing daemon checks for any removed files and removes them
 from index.
 If you want to rebuild the index from scratch, you can use the ``-f`` flag as above,
 or in the admin panel you can check the "build from scratch" checkbox.
 .. _ldap-setup:
 Setting up LDAP support
 -----------------------
 Kallithea supports LDAP authentication. In order
 to use LDAP, you have to install the python-ldap_ package. This package is
 available via PyPI, so you can install it by running::
     pip install python-ldap
 .. note:: ``python-ldap`` requires some libraries to be installed on
           your system, so before installing it check that you have at
           least the ``openldap`` and ``sasl`` libraries.
 Choose *Admin > Authentication*, click the ``kallithea.lib.auth_modules.auth_ldap`` button
 and then *Save*, to enable the LDAP plugin and configure its settings.
 Here's a typical LDAP setup::
  Connection settings
  Enable LDAP          = checked
  Host                 = host.example.com
  Port                 = 389
  Account              = <account>
  Password             = <password>
  Connection Security  = LDAPS connection
  Certificate Checks   = DEMAND
  Search settings
  Base DN              = CN=users,DC=host,DC=example,DC=org
  LDAP Filter          = (&(objectClass=user)(!(objectClass=computer)))
  LDAP Search Scope    = SUBTREE
  Attribute mappings
  Login Attribute      = uid
  First Name Attribute = firstName
  Last Name Attribute  = lastName
  Email Attribute      = mail
 If your user groups are placed in an Organisation Unit (OU) structure, the Search Settings configuration differs::
  Search settings
  Base DN              = DC=host,DC=example,DC=org
  LDAP Filter          = (&(memberOf=CN=your user group,OU=subunit,OU=unit,DC=host,DC=example,DC=org)(objectClass=user))
  LDAP Search Scope    = SUBTREE
 .. _enable_ldap:
 Enable LDAP : required
     Whether to use LDAP for authenticating users.
 .. _ldap_host:
 Host : required
     LDAP server hostname or IP address. Can be also a comma separated
     list of servers to support LDAP fail-over.
 .. _Port:
 Port : required
 for un-encrypted LDAP, 636 for SSL-encrypted LDAP.
 .. _ldap_account:
 Account : optional
     Only required if the LDAP server does not allow anonymous browsing of
     records.  This should be a special account for record browsing.  This
     will require `LDAP Password`_ below.
 .. _LDAP Password:
 Password : optional
     Only required if the LDAP server does not allow anonymous browsing of
     records.
 .. _Enable LDAPS:
 Connection Security : required
     Defines the connection to LDAP server
     No encryption
         Plain non encrypted connection
     LDAPS connection
         Enable LDAPS connections. It will likely require `Port`_ to be set to
         a different value (standard LDAPS port is 636). When LDAPS is enabled
         then `Certificate Checks`_ is required.
     START_TLS on LDAP connection
         START TLS connection
 .. _Certificate Checks:
 Certificate Checks : optional
     How SSL certificates verification is handled -- this is only useful when
     `Enable LDAPS`_ is enabled.  Only DEMAND or HARD offer full SSL security
     while the other options are susceptible to man-in-the-middle attacks.  SSL
     certificates can be installed to /etc/openldap/cacerts so that the
     DEMAND or HARD options can be used with self-signed certificates or
     certificates that do not have traceable certificates of authority.
     NEVER
         A serve certificate will never be requested or checked.
     ALLOW
         A server certificate is requested.  Failure to provide a
         certificate or providing a bad certificate will not terminate the
         session.
     TRY
         A server certificate is requested.  Failure to provide a
         certificate does not halt the session; providing a bad certificate
         halts the session.
     DEMAND
         A server certificate is requested and must be provided and
         authenticated for the session to proceed.
     HARD
         The same as DEMAND.
 .. _Base DN:
 Base DN : required
     The Distinguished Name (DN) where searches for users will be performed.
     Searches can be controlled by `LDAP Filter`_ and `LDAP Search Scope`_.
 .. _LDAP Filter:
 LDAP Filter : optional
     A LDAP filter defined by RFC 2254.  This is more useful when `LDAP
     Search Scope`_ is set to SUBTREE.  The filter is useful for limiting
     which LDAP objects are identified as representing Users for
     authentication.  The filter is augmented by `Login Attribute`_ below.
     This can commonly be left blank.
 .. _LDAP Search Scope:
 LDAP Search Scope : required
     This limits how far LDAP will search for a matching object.
     BASE
         Only allows searching of `Base DN`_ and is usually not what you
         want.
     ONELEVEL
         Searches all entries under `Base DN`_, but not Base DN itself.
     SUBTREE
         Searches all entries below `Base DN`_, but not Base DN itself.
         When using SUBTREE `LDAP Filter`_ is useful to limit object
         location.
 .. _Login Attribute:
 Login Attribute : required
     The LDAP record attribute that will be matched as the USERNAME or
     ACCOUNT used to connect to Kallithea.  This will be added to `LDAP
     Filter`_ for locating the User object.  If `LDAP Filter`_ is specified as
     "LDAPFILTER", `Login Attribute`_ is specified as "uid" and the user has
     connected as "jsmith" then the `LDAP Filter`_ will be augmented as below
     ::
         (&(LDAPFILTER)(uid=jsmith))
 .. _ldap_attr_firstname:
 First Name Attribute : required
     The LDAP record attribute which represents the user's first name.
 .. _ldap_attr_lastname:
 Last Name Attribute : required
     The LDAP record attribute which represents the user's last name.
 .. _ldap_attr_email:
 Email Attribute : required
     The LDAP record attribute which represents the user's email address.
 If all data are entered correctly, and python-ldap_ is properly installed
 users should be granted access to Kallithea with LDAP accounts.  At this
 time user information is copied from LDAP into the Kallithea user database.
 This means that updates of an LDAP user object may not be reflected as a
 user update in Kallithea.
 If You have problems with LDAP access and believe You entered correct
 information check out the Kallithea logs, any error messages sent from LDAP
 will be saved there.
 Active Directory
 ''''''''''''''''
 Kallithea can use Microsoft Active Directory for user authentication.  This
 is done through an LDAP or LDAPS connection to Active Directory.  The
 following LDAP configuration settings are typical for using Active
 Directory ::
  Base DN              = OU=SBSUsers,OU=Users,OU=MyBusiness,DC=v3sys,DC=local
  Login Attribute      = sAMAccountName
  First Name Attribute = givenName
  Last Name Attribute  = sn
  Email Attribute     = mail
 All other LDAP settings will likely be site-specific and should be
 appropriately configured.
 Authentication by container or reverse-proxy
 --------------------------------------------
 Kallithea supports delegating the authentication
 of users to its WSGI container, or to a reverse-proxy server through which all
 clients access the application.
 When these authentication methods are enabled in Kallithea, it uses the
 username that the container/proxy (Apache or Nginx, etc.) provides and doesn't
 perform the authentication itself. The authorization, however, is still done by
 Kallithea according to its settings.
 When a user logs in for the first time using these authentication methods,
 a matching user account is created in Kallithea with default permissions. An
 administrator can then modify it using Kallithea's admin interface.
 It's also possible for an administrator to create accounts and configure their
 permissions before the user logs in for the first time, using the :ref:`create-user` API.
 Container-based authentication
 ''''''''''''''''''''''''''''''
 In a container-based authentication setup, Kallithea reads the user name from
 the ``REMOTE_USER`` server variable provided by the WSGI container.
 After setting up your container (see `Apache with mod_wsgi`_), you'll need
 to configure it to require authentication on the location configured for
 Kallithea.
 Proxy pass-through authentication
 '''''''''''''''''''''''''''''''''
 In a proxy pass-through authentication setup, Kallithea reads the user name
 from the ``X-Forwarded-User`` request header, which should be configured to be
 sent by the reverse-proxy server.
 After setting up your proxy solution (see `Apache virtual host reverse proxy example`_,
 `Apache as subdirectory`_ or `Nginx virtual host example`_), you'll need to
 configure the authentication and add the username in a request header named
 ``X-Forwarded-User``.
 For example, the following config section for Apache sets a subdirectory in a
 reverse-proxy setup with basic auth:
 .. code-block:: apache
     <Location /someprefix>
       ProxyPass http://127.0.0.1:5000/someprefix
       ProxyPassReverse http://127.0.0.1:5000/someprefix
       SetEnvIf X-Url-Scheme https HTTPS=1
       AuthType Basic
       AuthName "Kallithea authentication"
       AuthUserFile /srv/kallithea/.htpasswd
       Require valid-user
       RequestHeader unset X-Forwarded-User
       RewriteEngine On
       RewriteCond %{LA-U:REMOTE_USER} (.+)
       RewriteRule .* - [E=RU:%1]
       RequestHeader set X-Forwarded-User %{RU}e
     </Location>
 .. note::
    If you enable proxy pass-through authentication, make sure your server is
    only accessible through the proxy. Otherwise, any client would be able to
    forge the authentication header and could effectively become authenticated
    using any account of their liking.
 Integration with issue trackers
 -------------------------------
 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::
 and have that replaced with a URL to the issue.
 This is achieved with following three variables in the ini file::
     issue_pat = (?:^#|\s#)(\w+)
     issue_server_link = https://issues.example.com/{repo}/issue/{id}
     issue_prefix = #
     issue_pat = #(\d+)
     issue_server_link = https://issues.example.com/{repo}/issue/\1
     issue_sub =
 ``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.
 commit messages will be treated as issue references. The expression can/should
 have one or more parenthesized groups that can later be referred to in
 ``issue_server_link`` and ``issue_sub`` (see below). If you prefer, named groups
 can be used instead of simple parenthesized groups.
 The default expression matches issues in the format ``#<number>``, e.g., ``#300``.
 If the pattern should only match if it is preceded by whitespace, add the
 following string before the actual pattern: ``(?:^|(?<=\s))``.
 If the pattern should only match if it is followed by whitespace, add the
 following string after the actual pattern: ``(?:$|(?=\s))``.
 These expressions use lookbehind and lookahead assertions of the Python regular
 expression module to avoid the whitespace to be part of the actual pattern,
 otherwise the link text will also contain that whitespace.
 Matched issue references are replaced with the link specified in
 ``issue_server_link``. ``{id}`` is replaced with the issue ID, and
 ``{repo}`` with the repository name.  Since the # is stripped away,
 ``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:
 ``issue_server_link``, in which any backreferences are resolved. Backreferences
 can be ``\1``, ``\2``, ... or for named groups ``\g<groupname>``.
 The special token ``{repo}`` is replaced with the full repository path
 (including repository groups), while token ``{repo_name}`` is replaced with the
 repository name (without repository groups).
 The link text is determined by ``issue_sub``, which can be a string containing
 backreferences to the groups specified in ``issue_pat``. If ``issue_sub`` is
 empty, then the text matched by ``issue_pat`` is used verbatim.
 The example settings shown above match issues in the format ``#<number>``.
 This will cause the text ``#300`` to be transformed into a link:
 .. code-block:: html
   <a href="https://issues.example.com/example_repo/issue/300">ISSUE-300</a>
   <a href="https://issues.example.com/example_repo/issue/300">#300</a>
 The following example transforms a text starting with either of 'pullrequest',
 'pull request' or 'PR', followed by an optional space, then a pound character
 (#) and one or more digits, into a link with the text 'PR #' followed by the
 digits::
     issue_pat = (pullrequest|pull request|PR) ?#(\d+)
     issue_server_link = https://issues.example.com/\2
     issue_sub = PR #\2
 The following example demonstrates how to require whitespace before the issue
 reference in order for it to be recognized, such that the text ``issue#123`` will
 not cause a match, but ``issue #123`` will::
     issue_pat = (?:^|(?<=\s))#(\d+)
     issue_server_link = https://issues.example.com/\1
     issue_sub =
 If needed, more than one pattern can be specified by appending a unique suffix to
 the variables. For example::
+the variables. For example, also demonstrating the use of named groups::
     issue_pat_wiki = (?:wiki-)(.+)
     issue_server_link_wiki = https://wiki.example.com/{id}
     issue_prefix_wiki = WIKI-
     issue_pat_wiki = wiki-(?P<pagename>\S+)
     issue_server_link_wiki = https://wiki.example.com/\g<pagename>
     issue_sub_wiki = WIKI-\g<pagename>
 With these settings, wiki pages can be referenced as wiki-some-id, and every
 such reference will be transformed into:
 .. code-block:: html
   <a href="https://wiki.example.com/some-id">WIKI-some-id</a>
 Refer to the `Python regular expression documentation`_ for more details about
 the supported syntax in ``issue_pat``, ``issue_server_link`` and ``issue_sub``.
 Hook management
 ---------------
 Hooks can be managed in similar way to that used in ``.hgrc`` files.
 To manage hooks, choose *Admin > Settings > Hooks*.
@@ @@ -499,12 +260,15 @@ By default, Kallithea uses UTF-8 encodin @@
 This is configurable as ``default_encoding`` in the .ini file.
 This affects many parts in Kallithea including user names, filenames, and
 encoding of commit messages. In addition Kallithea can detect if the ``chardet``
 library is installed. If ``chardet`` is detected Kallithea will fallback to it
 when there are encode/decode errors.
 The Mercurial encoding is configurable as ``hgencoding``. It is similar to
 setting the ``HGENCODING`` environment variable, but will override it.
 Celery configuration
 --------------------
 Kallithea can use the distributed task queue system Celery_ to run tasks like
 cloning repositories or sending emails.
@@ @@ -528,13 +292,16 @@ and add or change the ``celery.*`` and ` @@
 Remember that the ini files use the format with '.' and not with '_' like
 Celery. So for example setting `BROKER_HOST` in Celery means setting
 `broker.host` in the configuration file.
 To start the Celery process, run::
  paster celeryd <configfile.ini>
   kallithea-cli celery-run -c my.ini
 Extra options to the Celery worker can be passed after ``--`` - see ``-- -h``
 for more info.
 .. note::
    Make sure you run this command from the same virtualenv, and with the same
    user that Kallithea runs.
@@ @@ -549,12 +316,14 @@ directly which scheme/protocol Kallithea @@
 - With ``https_fixup = true``, the scheme will be taken from the
   ``X-Url-Scheme``, ``X-Forwarded-Scheme`` or ``X-Forwarded-Proto`` HTTP header
   (default ``http``).
 - With ``force_https = true`` the default will be ``https``.
 - With ``use_htsts = true``, Kallithea will set ``Strict-Transport-Security`` when using https.
 .. _nginx_virtual_host:
 Nginx virtual host example
 --------------------------
 Sample config for Nginx using proxy:
@@ @@ -603,13 +372,13 @@ Sample config for Nginx using proxy: @@
        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;
        ## uncomment root directive if you want to serve static files by nginx
        ## requires static_files = false in .ini file
-       #root /path/to/installation/kallithea/public;
+       #root /srv/kallithea/kallithea/kallithea/public;
        include         /etc/nginx/proxy.conf;
        location / {
             try_files $uri @kallithea;
+       }
        location @kallithea {
@@ @@ -637,12 +406,14 @@ pushes or large pushes:: @@
     proxy_read_timeout          7200;
     proxy_buffers               8 32k;
     client_max_body_size        1024m;
     client_body_buffer_size     128k;
     large_client_header_buffers 8 64k;
 .. _apache_virtual_host_reverse_proxy:
 Apache virtual host reverse proxy example
 -----------------------------------------
 Here is a sample configuration file for Apache using proxy:
@@ @@ -658,13 +429,13 @@ Here is a sample configuration file for @@
               # For Apache 2.2 and earlier, instead use:
               # Order allow,deny
               # Allow from all
             </Proxy>
             #important !
-            #Directive to properly generate url (clone url) for pylons
+            #Directive to properly generate url (clone url) for Kallithea
             ProxyPreserveHost On
             #kallithea instance
             ProxyPass / http://127.0.0.1:5000/
             ProxyPassReverse / http://127.0.0.1:5000/
@@ @@ -672,38 +443,42 @@ Here is a sample configuration file for @@
             #SetEnvIf X-Url-Scheme https HTTPS=1
     </VirtualHost>
 Additional tutorial
 http://pylonsbook.com/en/1.1/deployment.html#using-apache-to-proxy-requests-to-pylons
 .. _apache_subdirectory:
 Apache as subdirectory
 ----------------------
 Apache subdirectory part:
 .. code-block:: apache
     <Location /<someprefix> >
       ProxyPass http://127.0.0.1:5000/<someprefix>
       ProxyPassReverse http://127.0.0.1:5000/<someprefix>
     <Location /PREFIX >
       ProxyPass http://127.0.0.1:5000/PREFIX
       ProxyPassReverse http://127.0.0.1:5000/PREFIX
       SetEnvIf X-Url-Scheme https HTTPS=1
     </Location>
 Besides the regular apache setup you will need to add the following line
 into ``[app:main]`` section of your .ini file::
     filter-with = proxy-prefix
 Add the following at the end of the .ini file::
     [filter:proxy-prefix]
     use = egg:PasteDeploy#prefix
-    prefix = /<someprefix>
+    prefix = /PREFIX
 then change ``<someprefix>`` into your chosen prefix
 then change ``PREFIX`` into your chosen prefix
 .. _apache_mod_wsgi:
 Apache with mod_wsgi
 --------------------
 Alternatively, Kallithea can be set up with Apache under mod_wsgi. For
@@ @@ -752,33 +527,27 @@ Or if using a dispatcher WSGI script wit @@
 Apache will by default run as a special Apache user, on Linux systems
 usually ``www-data`` or ``apache``. If you need to have the repositories
 directory owned by a different user, use the user and group options to
 WSGIDaemonProcess to set the name of the user and group.
 .. note::
    If running Kallithea in multiprocess mode,
    make sure you set ``instance_id = *`` in the configuration so each process
    gets it's own cache invalidation key.
 Example WSGI dispatch script:
 .. code-block:: python
     import os
     os.environ["HGENCODING"] = "UTF-8"
     os.environ['PYTHON_EGG_CACHE'] = '/srv/kallithea/.egg-cache'
-    # sometimes it's needed to set the curent dir
+    # sometimes it's needed to set the current dir
     os.chdir('/srv/kallithea/')
     import site
     site.addsitedir("/srv/kallithea/venv/lib/python2.7/site-packages")
     ini = '/srv/kallithea/my.ini'
-    from paste.script.util.logging_config import fileConfig
+    from logging.config import fileConfig
     fileConfig(ini)
     from paste.deploy import loadapp
     application = loadapp('config:' + ini)
 Or using proper virtualenv activation:
@@ @@ -788,13 +557,13 @@ Or using proper virtualenv activation: @@
     execfile(activate_this, dict(__file__=activate_this))
     import os
     os.environ['HOME'] = '/srv/kallithea'
     ini = '/srv/kallithea/kallithea.ini'
-    from paste.script.util.logging_config import fileConfig
+    from logging.config import fileConfig
     fileConfig(ini)
     from paste.deploy import loadapp
     application = loadapp('config:' + ini)
 Other configuration files
@@ @@ -805,14 +574,14 @@ the ``init.d`` directory of the Kallithe @@
 .. __: https://kallithea-scm.org/repos/kallithea/files/tip/init.d/ .
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _python: http://www.python.org/
 .. _Python regular expression documentation: https://docs.python.org/2/library/re.html
 .. _Mercurial: https://www.mercurial-scm.org/
 .. _Celery: http://celeryproject.org/
 .. _Celery documentation: http://docs.celeryproject.org/en/latest/getting-started/index.html
 .. _RabbitMQ: http://www.rabbitmq.com/
 .. _Redis: http://redis.io/
 .. _python-ldap: http://www.python-ldap.org/
 .. _mercurial-server: http://www.lshift.net/mercurial-server.html
 .. _PublishingRepositories: https://www.mercurial-scm.org/wiki/PublishingRepositories

docs/theme/nature/static/nature.css_t

➞

Show inline comments

 /**
  * Sphinx stylesheet -- default theme
  * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  */
 @import url("basic.css");
 /* -- page layout ----------------------------------------------------------- */
 body {
     font-family: Arial, sans-serif;
     font-size: 100%;
     background-color: #111;
     color: #555;
     margin: 0;
@@ @@ -25,58 +25,58 @@ div.bodywrapper { @@
     margin: 0 0 0 230px;
+}
 hr{
     border: 1px solid #B1B4B6;
+}
 div.document {
     background-color: #eee;
+}
 div.body {
     background-color: #ffffff;
     color: #3E4349;
     padding: 0 30px 30px 30px;
     font-size: 0.8em;
+}
 div.footer {
     color: #555;
     width: 100%;
     padding: 13px 0;
     text-align: center;
     font-size: 75%;
+}
 div.footer a {
     color: #444;
     text-decoration: underline;
+}
 div.related {
     background-color: #577632;
     line-height: 32px;
     color: #fff;
     text-shadow: 0px 1px 0 #444;
     font-size: 0.80em;
+}
 div.related a {
     color: #E2F3CC;
+}
 div.sphinxsidebar {
     font-size: 0.75em;
     line-height: 1.5em;
+}
 div.sphinxsidebarwrapper{
     padding: 20px 0;
+}
 div.sphinxsidebar h3,
 div.sphinxsidebar h4 {
     font-family: Arial, sans-serif;
     color: #222;
     font-size: 1.2em;
     font-weight: normal;
@@ @@ -86,36 +86,35 @@ div.sphinxsidebar h4 { @@
     text-shadow: 1px 1px 0 white
+}
 div.sphinxsidebar h4{
     font-size: 1.1em;
+}
 div.sphinxsidebar h3 a {
     color: #444;
+}
 div.sphinxsidebar p {
     color: #888;
     padding: 5px 20px;
+}
 div.sphinxsidebar p.topless {
+}
 div.sphinxsidebar ul {
     margin: 10px 20px;
     padding: 0;
     color: #000;
+}
 div.sphinxsidebar a {
     color: #444;
+}
 div.sphinxsidebar input {
     border: 1px solid #ccc;
     font-family: sans-serif;
     font-size: 1em;
+}
@@ @@ -123,25 +122,25 @@ div.sphinxsidebar input[type=text]{ @@
     margin-left: 20px;
+}
 div.sphinxsidebar input[type=image] {
     border: 0;
+}
 /* -- body styles ----------------------------------------------------------- */
 a {
     color: #005B81;
     text-decoration: none;
+}
 a:hover {
     color: #E32E00;
     text-decoration: underline;
+}
 div.body h1,
 div.body h2,
 div.body h3,
 div.body h4,
 div.body h5,
 div.body h6 {
@@ @@ -150,82 +149,82 @@ div.body h6 { @@
     font-weight: normal;
     color: #212224;
     margin: 30px 0px 10px 0px;
     padding: 5px 0 5px 10px;
     text-shadow: 0px 1px 0 white
+}
 div.body h1 { border-top: 20px solid white; margin-top: 0; font-size: 200%; }
 div.body h2 { font-size: 150%; background-color: #C8D5E3; }
 div.body h3 { font-size: 120%; background-color: #D8DEE3; }
 div.body h4 { font-size: 110%; background-color: #D8DEE3; }
 div.body h5 { font-size: 100%; background-color: #D8DEE3; }
 div.body h6 { font-size: 100%; background-color: #D8DEE3; }
 a.headerlink {
     color: #c60f0f;
     font-size: 0.8em;
     padding: 0 4px 0 4px;
     text-decoration: none;
+}
 a.headerlink:hover {
     background-color: #c60f0f;
     color: white;
+}
 div.body p, div.body dd, div.body li {
     line-height: 1.5em;
+}
 div.admonition p.admonition-title + p {
     display: inline;
+}
 div.highlight{
     background-color: white;
+}
 div.note {
     background-color: #eee;
     border: 1px solid #ccc;
+}
 div.seealso {
     background-color: #ffc;
     border: 1px solid #ff6;
+}
 div.topic {
     background-color: #eee;
+}
 div.warning {
     background-color: #ffe4e4;
     border: 1px solid #f66;
+}
 p.admonition-title {
     display: inline;
+}
 p.admonition-title:after {
     content: ":";
+}
 pre {
     padding: 10px;
     background-color: White;
     color: #222;
     line-height: 1.2em;
     border: 1px solid #C6C9CB;
     font-size: 1.2em;
     margin: 1.5em 0 1.5em 0;
     box-shadow: 1px 1px 1px #d8d8d8;
+}
 tt {
     background-color: #ecf0f3;
     color: #222;
     padding: 1px 2px;
     font-size: 1.2em;
     font-family: monospace;

docs/upgrade.rst

➞

Show inline comments

@@ new file 100644 @@
 .. _upgrade:
 ===================
 Upgrading Kallithea
 ===================
 This describes the process for upgrading Kallithea, independently of the
 Kallithea installation method.
 .. note::
     If you are upgrading from a RhodeCode installation, you must first
     install Kallithea 0.3.2 and follow the instructions in the 0.3.2
     README to perform a one-time conversion of the database from
     RhodeCode to Kallithea, before upgrading to the latest version
     of Kallithea.
 . Stop the Kallithea web application
 -------------------------------------
 This step depends entirely on the web server software used to serve
 Kallithea, but in any case, Kallithea should not be running during
 the upgrade.
 .. note::
     If you're using Celery, make sure you stop all instances during the
     upgrade.
 . Create a backup of both database and configuration
 -----------------------------------------------------
 You are of course strongly recommended to make backups regularly, but it
 is *especially* important to make a full database and configuration
 backup before performing a Kallithea upgrade.
 Back up your configuration
 ^^^^^^^^^^^^^^^^^^^^^^^^^^
 Make a copy of your Kallithea configuration (``.ini``) file.
 If you are using :ref:`rcextensions <customization>`, you should also
 make a copy of the entire ``rcextensions`` directory.
 Back up your database
 ^^^^^^^^^^^^^^^^^^^^^
 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.
 If using MySQL, please consult the documentation for the ``mysqldump``
 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``.
 . Activate or recreate the Kallithea virtual environment (if any)
 ------------------------------------------------------------------
 .. note::
     If you did not install Kallithea in a virtual environment, skip this step.
 For major upgrades, e.g. from 0.3.x to 0.4.x, it is recommended to create a new
 virtual environment, rather than reusing the old. For minor upgrades, e.g.
 within the 0.4.x range, this is not really necessary (but equally fine).
 To create a new virtual environment, please refer to the appropriate
 installation page for details. After creating and activating the new virtual
 environment, proceed with the rest of the upgrade process starting from the next
 section.
 To reuse the same virtual environment, first activate it, then verify that you
 are using the correct environment by running::
     pip freeze
 This will list all packages installed in the current environment. If
 Kallithea isn't listed, deactivate the environment and then activate the correct
 one, or recreate a new environment. See the appropriate installation page for
 details.
 . Install new version of Kallithea
 -----------------------------------
 Please refer to the instructions for the installation method you
 originally used to install Kallithea.
 If you originally installed using pip, it is as simple as::
     pip install --upgrade kallithea
 If you originally installed from version control, assuming you did not make
 private changes (in which case you should adapt the instructions accordingly)::
     cd my-kallithea-clone
     hg parent   # make a note of the original revision
     hg pull
     hg update
     hg parent   # make a note of the new revision
     pip install --upgrade -e .
 .. _upgrade_config:
 . Upgrade your configuration
 -----------------------------
 Run the following command to create a new configuration (``.ini``) file::
     kallithea-cli config-create new.ini
 Then compare it with your old config file and copy over the required
 configuration values from the old to the new file.
 .. note::
     Please always make sure your ``.ini`` files are up to date. Errors
     can often be caused by missing parameters added in new versions.
 .. _upgrade_db:
 . Upgrade your database
 ------------------------
 .. note::
     If you are *downgrading* Kallithea, you should perform the database
     migration step *before* installing the older version. (That is,
     always perform migrations using the most recent of the two versions
     you're migrating between.)
 First, run the following command to see your current database version::
     alembic -c new.ini current
 Typical output will be something like "9358dc3d6828 (head)", which is
 the current Alembic database "revision ID". Write down the entire output
 for troubleshooting purposes.
 The output will be empty if you're upgrading from Kallithea 0.3.x or
 older. That's expected. If you get an error that the config file was not
 found or has no ``[alembic]`` section, see the next section.
 Next, if you are performing an *upgrade*: Run the following command to
 upgrade your database to the current Kallithea version::
     alembic -c new.ini upgrade head
 If you are performing a *downgrade*: Run the following command to
 downgrade your database to the given version::
     alembic -c new.ini downgrade 0.4
 Alembic will show the necessary migrations (if any) as it executes them.
 If no "ERROR" is displayed, the command was successful.
 Should an error occur, the database may be "stranded" half-way
 through the migration, and you should restore it from backup.
 Enabling old Kallithea config files for Alembic use
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Kallithea configuration files created before the introduction of Alembic
 (i.e. predating Kallithea 0.4) need to be updated for use with Alembic.
 Without this, Alembic will fail with an error like this::
     FAILED: No config file 'my.ini' found, or file has no '[alembic]' section
 .. note::
     If you followed this upgrade guide correctly, you will have created a
     new configuration file in section :ref:`Upgrading your configuration
     <upgrade_config>`. When calling Alembic, make
     sure to use this new config file. In this case, you should not get any
     errors and the below manual steps should not be needed.
 If Alembic complains specifically about a missing ``alembic.ini``, it is
 likely because you did not specify a config file using the ``-c`` option.
 On the other hand, if the mentioned config file actually exists, you
 need to append the following lines to it::
     [alembic]
     script_location = kallithea:alembic
 Your config file should now work with Alembic.
 . Prepare the front-end
 ------------------------
 Starting with Kallithea 0.4, external front-end dependencies are no longer
 shipped but need to be downloaded and/or generated at installation time. Run the
 following command::
     kallithea-cli front-end-build
 . Rebuild the Whoosh full-text index
 -------------------------------------
 It is recommended that you rebuild the Whoosh index after upgrading since
 new Whoosh versions can introduce incompatible index changes.
 . Start the Kallithea web application
 --------------------------------------
 This step once again depends entirely on the web server software used to
 serve Kallithea.
 If you were running Kallithea 0.3.x or older and were using ``paster serve
 my.ini`` before, then the corresponding command in Kallithea 0.4 and later is::
     gearbox serve -c new.ini
 Before starting the new version of Kallithea, you may find it helpful to
 clear out your log file so that new errors are readily apparent.
 .. note::
     If you're using Celery, make sure you restart all instances of it after
     upgrade.
 . Update Git repository hooks
 -------------------------------
 It is possible that an upgrade involves changes to the Git hooks installed by
 Kallithea. As these hooks are created inside the repositories on the server
 filesystem, they are not updated automatically when upgrading Kallithea itself.
 To update the hooks of your Git repositories:
 * Go to *Admin > Settings > Remap and Rescan*
 * Select the checkbox *Install Git hooks*
 * Click the button *Rescan repositories*
 .. note::
     Kallithea does not use hooks on Mercurial repositories. This step is thus
     not necessary if you only have Mercurial repositories.
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv

docs/usage/customization.rst

➞

Show inline comments

@@ new file 100644 @@
 .. _customization:
 =============
 Customization
 =============
 There are several ways to customize Kallithea to your needs depending on what
 you want to achieve.
 HTML/JavaScript/CSS customization
 ---------------------------------
 To customize the look-and-feel of the web interface (for example to add a
 company banner or some JavaScript widget or to tweak the CSS style definitions)
 you can enter HTML code (possibly with JavaScript and/or CSS) directly via the
 *Admin > Settings > Global > HTML/JavaScript customization
 block*.
 Style sheet customization with Less
 -----------------------------------
 Kallithea uses `Bootstrap 3`_ and Less_ for its style definitions. If you want
 to make some customizations, we recommend to do so by creating a ``theme.less``
 file. When you create a file named ``theme.less`` in the Kallithea root
 directory, you can use this file to override the default style. For example,
 you can use this to override ``@kallithea-theme-main-color``,
 ``@kallithea-logo-url`` or other `Bootstrap variables`_.
 After creating the ``theme.less`` file, you need to regenerate the CSS files, by
 running::
     kallithea-cli front-end-build --no-install-deps
 .. _bootstrap 3: https://getbootstrap.com/docs/3.3/
 .. _bootstrap variables: https://getbootstrap.com/docs/3.3/customize/#less-variables
 .. _less: http://lesscss.org/
 Behavioral customization: rcextensions
 --------------------------------------
 Some behavioral customization can be done in Python using ``rcextensions``, a
 custom Python package that can extend Kallithea functionality.
 With ``rcextensions`` it's possible to add additional mappings for Whoosh
 indexing and statistics, to add additional code into the push/pull/create/delete
 repository hooks (for example to send signals to build bots such as Jenkins) and
 even to monkey-patch certain parts of the Kallithea source code (for example
 overwrite an entire function, change a global variable, ...).
 To generate a skeleton extensions package, run::
     kallithea-cli extensions-create -c my.ini
 This will create an ``rcextensions`` package next to the specified ``ini`` file.
 See the ``__init__.py`` file inside the generated ``rcextensions`` package
 for more details.
 Behavioral customization: code changes
 --------------------------------------
 As Kallithea is open-source software, you can make any changes you like directly
 in the source code.
 We encourage you to send generic improvements back to the
 community so that Kallithea can become better. See :ref:`contributing` for more
 details.

docs/usage/debugging.rst

➞

Show inline comments

@@ @@ -22,12 +22,12 @@ console. This generally helps a lot to t @@
 Enable interactive debug mode
 -----------------------------
 To enable interactive debug mode simply comment out ``set debug = false`` in
 the .ini file. This will trigger an interactive debugger each time
-there is an error in the browser, or send a http link if an error occured in the backend. This
+there is an error in the browser, or send a http link if an error occurred in the backend. This
 is a great tool for fast debugging as you get a handy Python console right
 in the web view.
 .. warning:: NEVER ENABLE THIS ON PRODUCTION! The interactive console
              can be a serious security threat to your system.

docs/usage/email.rst

➞

Show inline comments

@@ @@ -9,14 +9,23 @@ these contain correct values, Kallithea @@
 described below. If the email configuration is not correct so that emails
 cannot be sent, all mails will show up in the log output.
 Before any email can be sent, an SMTP server has to be configured using the
 configuration file setting ``smtp_server``. If required for that server, specify
 a username (``smtp_username``) and password (``smtp_password``), a non-standard
 port (``smtp_port``), encryption settings (``smtp_use_tls`` or ``smtp_use_ssl``)
 and/or specific authentication parameters (``smtp_auth``).
 port (``smtp_port``), whether to use "SSL" when connecting (``smtp_use_ssl``)
 or use STARTTLS (``smtp_use_tls``), and/or specify special ESMTP "auth" features
 (``smtp_auth``).
 For example, for sending through gmail, use::
     smtp_server = smtp.gmail.com
     smtp_username = username
     smtp_password = password
     smtp_port = 465
     smtp_use_ssl = true
 Application emails
 ------------------
 Kallithea sends an email to `users` on several occasions:
@@ @@ -64,29 +73,24 @@ where ``<type>`` is one of: @@
 Error emails
 ------------
 When an exception occurs in Kallithea -- and unless interactive debugging is
 enabled using ``set debug = true`` in the ``[app:main]`` section of the
 configuration file -- an email with exception details is sent by WebError_'s
 ``ErrorMiddleware`` to the addresses specified in ``email_to`` in the
 configuration file.
 configuration file -- an email with exception details is sent by backlash_
 to the addresses specified in ``email_to`` in the configuration file.
 Recipients will see these emails originating from the sender specified in the
 ``error_email_from`` setting in the configuration file. This setting can either
 contain only an email address, like `kallithea-noreply@example.com`, or both
 a name and an address in the following format: `Kallithea Errors
 <kallithea-noreply@example.com>`.
 *Note:* The WebError_ package does not respect ``smtp_port`` and assumes the
 standard SMTP port (25). If you have a remote SMTP server with a different port,
 you could set up a local forwarding SMTP server on port 25.
 References
 ----------
 - `Error Middleware (Pylons documentation) <http://pylons-webframework.readthedocs.org/en/latest/debugging.html#error-middleware>`_
 - `ErrorHandler (Pylons modules documentation) <http://pylons-webframework.readthedocs.org/en/latest/modules/middleware.html#pylons.middleware.ErrorHandler>`_
-.. _WebError: https://pypi.python.org/pypi/WebError
+.. _backlash: https://github.com/TurboGears/backlash

docs/usage/general.rst

➞

Show inline comments

@@ @@ -5,24 +5,24 @@ General Kallithea usage @@
 =======================
 Repository deletion
 -------------------
-Currently when an admin or owner deletes a repository, Kallithea does
+When an admin or owner deletes a repository, Kallithea does
 not physically delete said repository from the filesystem, but instead
 renames it in a special way so that it is not possible to push, clone
 or access the repository.
 There is a special command for cleaning up such archived repositories::
-    paster cleanup-repos --older-than=30d my.ini
+    kallithea-cli repo-purge-deleted -c my.ini --older-than=30d
 This command scans for archived repositories that are older than
 days, displays them, and asks if you want to delete them (unless given
-the ``--dont-ask`` flag). If you host a large amount of repositories with
+the ``--no-ask`` flag). If you host a large amount of repositories with
 forks that are constantly being deleted, it is recommended that you run this
 command via crontab.
 It is worth noting that even if someone is given administrative access to
 Kallithea and deletes a repository, you can easily restore such an action by
 renaming the repository directory, removing the ``rm__<date>`` prefix.
@@ @@ -148,13 +148,13 @@ Specific features configurable in the Ad @@
 In general, the Admin settings should be self-explanatory and will not be
 described in more detail in this documentation. However, there are a few
 features that merit further explanation.
 Repository extra fields
-~~~~~~~~~~~~~~~~~~~~~~~
+^^^^^^^^^^^^^^^^^^^^^^^
 In the *Visual* tab, there is an option "Use repository extra
 fields", which allows to set custom fields for each repository in the system.
 Once enabled site-wide, the custom fields can be edited per-repository under
 *Options* | *Settings* | *Extra Fields*.
@@ @@ -162,13 +162,13 @@ Once enabled site-wide, the custom field @@
 Example usage of such fields would be to define company-specific information
 into repositories, e.g., defining a ``repo_manager`` key that would give info
 about a manager of each repository.  There's no limit for adding custom fields.
 Newly created fields are accessible via the API.
 Meta tagging
-~~~~~~~~~~~~
+^^^^^^^^^^^^
 In the *Visual* tab, option "Stylify recognised meta tags" will cause Kallithea
 to turn certain text fragments in repository and repository group
 descriptions into colored tags. Currently recognised tags are::
     [featured]

docs/usage/performance.rst

➞

Show inline comments

 .. _performance:
 ================================
 Optimizing Kallithea performance
 ================================
 When serving a large amount of big repositories, Kallithea can start
 performing slower than expected. Because of the demanding nature of handling large
 amounts of data from version control systems, here are some tips on how to get
 the best performance.
 When serving a large amount of big repositories, Kallithea can start performing
 slower than expected. Because of the demanding nature of handling large amounts
 of data from version control systems, here are some tips on how to get the best
 performance.
 * Kallithea is often I/O bound, and hence a fast disk (SSD/SAN) is
   usually more important than a fast CPU.
 Fast storage
 ------------
 * Sluggish loading of the front page can easily be fixed by grouping repositories or by
   increasing cache size (see below). This includes using the lightweight dashboard
   option and ``vcs_full_cache`` setting in .ini file.
 Kallithea is often I/O bound, and hence a fast disk (SSD/SAN) and plenty of RAM
 is usually more important than a fast CPU.
 Follow these few steps to improve performance of Kallithea system.
 Caching
 -------
 . Increase cache
 Tweak beaker cache settings in the ini file. The actual effect of that is
 questionable.
     Tweak beaker cache settings in the ini file. The actual effect of that
     is questionable.
 . Switch from SQLite to PostgreSQL or MySQL
 Database
 --------
     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. Switching to MySQL or PostgreSQL will result in an immediate
     performance increase. A tool like SQLAlchemyGrate_ can be used for
     migrating to another database platform.
 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.
 . Scale Kallithea horizontally
 Switching to MySQL or PostgreSQL will result in an immediate performance
 increase. A tool like SQLAlchemyGrate_ can be used for migrating to another
 database platform.
     Scaling horizontally can give huge performance benefits when dealing with
     large amounts of traffic (many users, CI servers, etc.). Kallithea can be
     scaled horizontally on one (recommended) or multiple machines.
 Horizontal scaling
 ------------------
     It is generally possible to run WSGI applications multithreaded, so that
     several HTTP requests are served from the same Python process at once. That
     can in principle give better utilization of internal caches and less
     process overhead.
 Scaling horizontally means running several Kallithea instances and let them
 share the load. That can give huge performance benefits when dealing with large
 amounts of traffic (many users, CI servers, etc.). Kallithea can be scaled
 horizontally on one (recommended) or multiple machines.
     One danger of running multithreaded is that program execution becomes much
     more complex; programs must be written to consider all combinations of
     events and problems might depend on timing and be impossible to reproduce.
 It is generally possible to run WSGI applications multithreaded, so that
 several HTTP requests are served from the same Python process at once. That can
 in principle give better utilization of internal caches and less process
 overhead.
     Kallithea can't promise to be thread-safe, just like the embedded Mercurial
     backend doesn't make any strong promises when used as Kallithea uses it.
     Instead, we recommend scaling by using multiple server processes.
 One danger of running multithreaded is that program execution becomes much more
 complex; programs must be written to consider all combinations of events and
 problems might depend on timing and be impossible to reproduce.
     Web servers with multiple worker processes (such as ``mod_wsgi`` with the
     ``WSGIDaemonProcess`` ``processes`` parameter) will work out of the box.
 Kallithea can't promise to be thread-safe, just like the embedded Mercurial
 backend doesn't make any strong promises when used as Kallithea uses it.
 Instead, we recommend scaling by using multiple server processes.
     In order to scale horizontally on multiple machines, you need to do the
     following:
 Web servers with multiple worker processes (such as ``mod_wsgi`` with the
 ``WSGIDaemonProcess`` ``processes`` parameter) will work out of the box.
     - Each instance needs its own .ini file and unique ``instance_id`` set.
 In order to scale horizontally on multiple machines, you need to do the
 following:
     - Each instance's ``data`` storage needs to be configured to be stored on a
       shared disk storage, preferably together with repositories. This ``data``
       dir contains template caches, sessions, whoosh index and is used for
       task locking (so it is safe across multiple instances). Set the
       ``cache_dir``, ``index_dir``, ``beaker.cache.data_dir``, ``beaker.cache.lock_dir``
       variables in each .ini file to a shared location across Kallithea instances
@@ @@ -68,7 +74,45 @@ Follow these few steps to improve perfor @@
       shared RabbitMQ server)
     - Load balance using round robin or IP hash, recommended is writing LB rules
       that will separate regular user traffic from automated processes like CI
       servers or build bots.
 Serve static files directly from the web server
 -----------------------------------------------
 With the default ``static_files`` ini setting, the Kallithea WSGI application
 will take care of serving the static files from ``kallithea/public/`` at the
 root of the application URL.
 The actual serving of the static files is very fast and unlikely to be a
 problem in a Kallithea setup - the responses generated by Kallithea from
 database and repository content will take significantly more time and
 resources.
 To serve static files from the web server, use something like this Apache config
 snippet::
         Alias /images/ /srv/kallithea/kallithea/kallithea/public/images/
         Alias /css/ /srv/kallithea/kallithea/kallithea/public/css/
         Alias /js/ /srv/kallithea/kallithea/kallithea/public/js/
         Alias /codemirror/ /srv/kallithea/kallithea/kallithea/public/codemirror/
         Alias /fontello/ /srv/kallithea/kallithea/kallithea/public/fontello/
 Then disable serving of static files in the ``.ini`` ``app:main`` section::
         static_files = false
 If using Kallithea installed as a package, you should be able to find the files
 under ``site-packages/kallithea``, either in your Python installation or in your
 virtualenv. When upgrading, make sure to update the web server configuration
 too if necessary.
 It might also be possible to improve performance by configuring the web server
 to compress responses (served from static files or generated by Kallithea) when
 serving them. That might also imply buffering of responses - that is more
 likely to be a problem; large responses (clones or pulls) will have to be fully
 processed and spooled to disk or memory before the client will see any
 response. See the documentation for your web server.
 .. _SQLAlchemyGrate: https://github.com/shazow/sqlalchemygrate

docs/usage/troubleshooting.rst

➞

Show inline comments

@@ @@ -60,13 +60,13 @@ Troubleshooting @@
 :Q: **UnicodeDecodeError on Apache mod_wsgi**
 :A: Please read: https://docs.djangoproject.com/en/dev/howto/deployment/wsgi/modwsgi/#if-you-get-a-unicodeencodeerror.
+|
 :Q: **Requests hanging on Windows**
-:A: Please try out with disabled Antivirus software, there are some known problems with Eset Anitivirus. Make sure
+:A: Please try out with disabled Antivirus software, there are some known problems with Eset Antivirus. Make sure
     you have installed the latest Windows patches (especially KB2789397).
 .. _virtualenv: http://pypi.python.org/pypi/virtualenv
 .. _python: http://www.python.org/
 .. _mercurial: https://www.mercurial-scm.org/

docs/usage/vcs_notes.rst

➞

Show inline comments

@@ file copied from docs/usage/vcs_support.rst to docs/usage/vcs_notes.rst @@
 .. _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.
 .. _vcs_notes:
 You can always disable Git or Mercurial support by editing the
 file ``kallithea/__init__.py`` and commenting out the backend.
 .. code-block:: python
 ===================================
 Version control systems usage notes
 ===================================
    BACKENDS = {
        'hg': 'Mercurial repository',
        #'git': 'Git repository',
+   }
 Git support
 -----------
 .. _importing:
 Web server with chunked encoding
 ````````````````````````````````
 Importing existing repositories
 -------------------------------
 There are two main methods to import repositories in Kallithea: via the web
 interface or via the filesystem. If you have a large number of repositories to
 import, importing them via the filesystem is more convenient.
 Importing via web interface
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 For a small number of repositories, it may be easier to create the target
 repositories through the Kallithea web interface, via *Admin > Repositories* or
 via the *Add Repository* button on the entry page of the web interface.
 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.
 Repositories can be nested in repository groups by first creating the group (via
 *Admin > Repository Groups* or via the *Add Repository Group* button on the
 entry page of the web interface) and then selecting the appropriate group when
 adding the repository.
 The paster server is controlled in the .ini file::
 After creation of the (empty) repository, push the existing commits to the
 *Clone URL* displayed on the repository summary page. For Git repositories,
 first add the *Clone URL* as remote, then push the commits to that remote.  The
 specific commands to execute are shown under the *Existing repository?* section
 of the new repository's summary page.
 A benefit of this method particular for Git repositories, is that the
 Kallithea-specific Git hooks are installed automatically.  For Mercurial, no
 hooks are required anyway.
     use = egg:waitress#main
 Importing via the filesystem
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 The alternative method of importing repositories consists of creating the
 repositories in the desired hierarchy on the filesystem and letting Kallithea
 scan that location.
 or::
     use = egg:gunicorn#main
 All repositories are stored in a central location on the filesystem. This
 location is specified during installation (via ``db-create``) and can be reviewed
 at *Admin > Settings > VCS > Location of repositories*. Repository groups
 (defined in *Admin > Repository Groups*) are represented by a directory in that
 repository location. Repositories of the repository group are nested under that
 directory.
 Also make sure to comment out the following options::
 To import a set of repositories and organize them in a certain repository group
 structure, first place clones in the desired hierarchy at the configured
 repository location.
 These clones should be created without working directory. For Mercurial, this is
 done with ``hg clone -U``, for Git with ``git clone --bare``.
 When the repositories are added correctly on the filesystem:
     threadpool_workers =
     threadpool_max_requests =
     use_threadpool =
 * go to *Admin > Settings > Remap and Rescan* in the Kallithea web interface
 * select the *Install Git hooks* checkbox when importing Git repositories
 * click *Rescan Repositories*
 This step will scan the filesystem and create the appropriate repository groups
 and repositories in Kallithea.
 *Note*: Once repository groups have been created this way, manage their access
 permissions through the Kallithea web interface.
 Mercurial support
 -----------------
 Mercurial-specific notes
 ------------------------
 Working with Mercurial subrepositories
 ``````````````````````````````````````
 Working with subrepositories
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 This section explains how to use Mercurial subrepositories_ in Kallithea.
 Example usage::
     ## init a simple repo
@@ @@ -79,9 +102,7 @@ subrepository link sends you to the prop @@
 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/

init.d/celeryd-upstart.conf

➞

Show inline comments

 # celeryd - run the celeryd daemon as an upstart job for kallithea
 # Change variables/paths as necessary and place file /etc/init/celeryd.conf
 # start/stop/restart as normal upstart job (ie: $ start celeryd)
 description	"Celery for Kallithea Mercurial Server"
 author		"Matt Zuba <matt.zuba@goodwillaz.org"
 description     "Celery for Kallithea Mercurial Server"
 author          "Matt Zuba <matt.zuba@goodwillaz.org"
 start on starting kallithea
 stop on stopped kallithea
 respawn
@@ @@ -18,13 +18,13 @@ env HOME=/var/hg @@
 env USER=hg
 # To use group (if different from user), you must edit sudoers file and change
 # root's entry from (ALL) to (ALL:ALL)
 # env GROUP=hg
 script
-    COMMAND="/var/hg/.virtualenvs/kallithea/bin/paster celeryd $APPINI --pidfile=$PIDFILE"
+    COMMAND="/var/hg/.virtualenvs/kallithea/bin/kallithea-cli celery-run -c $APPINI -- --pidfile=$PIDFILE"
     if [ -z "$GROUP" ]; then
         exec sudo -u $USER $COMMAND
     else
         exec sudo -u $USER -g $GROUP $COMMAND
     fi
 end script

init.d/kallithea-daemon-arch

➞

Show inline comments

@@ @@ -9,21 +9,21 @@ @@
 DAEMON=kallithea
 APP_HOMEDIR="/srv"
 APP_PATH="$APP_HOMEDIR/$DAEMON"
 CONF_NAME="production.ini"
 LOG_FILE="/var/log/$DAEMON.log"
 PID_FILE="/run/daemons/$DAEMON"
-APPL=/usr/bin/paster
+APPL=/usr/bin/gearbox
 RUN_AS="*****"
 ARGS="serve --daemon \
 --user=$RUN_AS \
 --group=$RUN_AS \
 --pid-file=$PID_FILE \
 --log-file=$LOG_FILE \
 $APP_PATH/$CONF_NAME"
+-c $APP_PATH/$CONF_NAME"
 [ -r /etc/conf.d/$DAEMON ] && . /etc/conf.d/$DAEMON
 if [[ -r $PID_FILE ]]; then
     read -r PID < "$PID_FILE"
     if [[ $PID && ! -d /proc/$PID ]]; then
@@ @@ -44,13 +44,13 @@ start) @@
         stat_fail
         exit 1
     fi
     ;;
 stop)
     stat_busy "Stopping $DAEMON"
-    [ -n "$PID" ] && kill $PID &>/dev/null
     [ -n "$PID" ] && kill $PID &>/dev/null
     if [ $? = 0 ]; then
         rm_daemon $DAEMON
         stat_done
     else
         stat_fail
         exit 1
@@ @@ -64,7 +64,7 @@ restart) @@
 status)
     stat_busy "Checking $name status";
     ck_status $name
     ;;
 *)
     echo "usage: $0 {start|stop|restart|status}"
 esac
@@ \ No newline at end of file @@
 esac

init.d/kallithea-daemon-debian

➞

Show inline comments

 #!/bin/sh -e
 ########################################
 #### THIS IS A DEBIAN INIT.D SCRIPT ####
 ########################################
 ### BEGIN INIT INFO
-# Provides:          kallithea
 # Provides:          kallithea
 # Required-Start:    $all
 # Required-Stop:     $all
 # Default-Start:     2 3 4 5
 # Default-Stop:      0 1 6
 # Short-Description: starts instance of kallithea
 # Description:       starts instance of kallithea using start-stop-daemon
 ### END INIT INFO
 APP_NAME="kallithea"
 APP_HOMEDIR="opt"
 APP_PATH="/$APP_HOMEDIR/$APP_NAME"
 CONF_NAME="production.ini"
 PID_PATH="$APP_PATH/$APP_NAME.pid"
 LOG_PATH="$APP_PATH/$APP_NAME.log"
 PYTHON_PATH="/$APP_HOMEDIR/$APP_NAME-venv"
 RUN_AS="root"
 DAEMON="$PYTHON_PATH/bin/paster"
 DAEMON="$PYTHON_PATH/bin/gearbox"
 DAEMON_OPTS="serve --daemon \
  --user=$RUN_AS \
  --group=$RUN_AS \
  --pid-file=$PID_PATH \
  --log-file=$LOG_PATH  $APP_PATH/$CONF_NAME"
  --log-file=$LOG_PATH -c $APP_PATH/$CONF_NAME"
 start() {
   echo "Starting $APP_NAME"
   PYTHON_EGG_CACHE="/tmp" start-stop-daemon -d $APP_PATH \
       --start --quiet \
       --pidfile $PID_PATH \
       --user $RUN_AS \
       --exec $DAEMON -- $DAEMON_OPTS
+}
 stop() {
   echo "Stopping $APP_NAME"
   start-stop-daemon -d $APP_PATH \
       --stop --quiet \
       --pidfile $PID_PATH || echo "$APP_NAME - Not running!"
   if [ -f $PID_PATH ]; then
     rm $PID_PATH
   fi
+}
 status() {
   echo -n "Checking status of $APP_NAME ... "
   pid=`cat $PID_PATH`
   status=`ps ax | grep $pid | grep -ve grep`
   if [ "$?" -eq 0 ]; then
     echo "running"
   else
     echo "NOT running"
   fi
+}
 case "$1" in
   status)
    status
     ;;
   start)
     start
@@ @@ -84,7 +84,7 @@ case "$1" in @@
     ### start ###
     start
     ;;
   *)
     echo "Usage: $0 {start|stop|restart}"
     exit 1
 esac
@@ \ No newline at end of file @@
 esac

init.d/kallithea-daemon-gentoo

➞

Show inline comments

@@ @@ -13,19 +13,19 @@ PID_PATH="$APP_PATH/$APP_NAME.pid" @@
 LOG_PATH="$APP_PATH/$APP_NAME.log"
 PYTHON_PATH="/home/$APP_HOMEDIR/v-env"
 RUN_AS="username"
-DAEMON="$PYTHON_PATH/bin/paster"
+DAEMON="$PYTHON_PATH/bin/gearbox"
 DAEMON_OPTS="serve --daemon \
 --user=$RUN_AS \
 --group=$RUN_AS \
 --pid-file=$PID_PATH \
 --log-file=$LOG_PATH  $APP_PATH/$CONF_NAME"
+--log-file=$LOG_PATH -c $APP_PATH/$CONF_NAME"
 #extra options
 opts="${opts} restartdelay"
 depend() {
     need nginx
@@ @@ -53,9 +53,9 @@ stop() { @@
+}
 restartdelay() {
     #stop()
     echo "sleep3"
     sleep 3
     #start()
+}

init.d/kallithea-daemon-redhat

➞

Show inline comments

@@ @@ -17,30 +17,30 @@ APP_NAME="kallithea" @@
 # since this is a web app, it should go in /var/www
 APP_PATH="/var/www/$APP_NAME"
 CONF_NAME="production.ini"
 # write to wherever the PID should be stored, just ensure
-# that the user you run paster as has the appropriate permissions
+# that the user you run gearbox as has the appropriate permissions
 # same goes for the log file
 PID_PATH="/var/run/kallithea/pid"
 LOG_PATH="/var/log/kallithea/kallithea.log"
 # replace this with the path to the virtual environment you
 # made for Kallithea
 PYTHON_PATH="/opt/python_virtualenvironments/kallithea-venv"
 RUN_AS="kallithea"
-DAEMON="$PYTHON_PATH/bin/paster"
+DAEMON="$PYTHON_PATH/bin/gearbox"
 DAEMON_OPTS="serve --daemon \
     --user=$RUN_AS \
     --group=$RUN_AS \
     --pid-file=$PID_PATH \
     --log-file=$LOG_PATH $APP_PATH/$CONF_NAME"
+    --log-file=$LOG_PATH -c $APP_PATH/$CONF_NAME"
 DESC="kallithea-server"
 LOCK_FILE="/var/lock/subsys/$APP_NAME"
 # source CentOS init functions
 . /etc/init.d/functions
@@ @@ -126,7 +126,7 @@ case "$1" in @@
   *)
     echo $"Usage: $0 {start|stop|restart|status}"
     RETVAL=1
     ;;
 esac
 exit $RETVAL
@@ \ No newline at end of file @@
 exit $RETVAL

init.d/kallithea-upstart.conf

➞

Show inline comments

 # kallithea - run the kallithea daemon as an upstart job
 # Change variables/paths as necessary and place file /etc/init/kallithea.conf
 # start/stop/restart as normal upstart job (ie: $ start kallithea)
 description	"Kallithea Mercurial Server"
 author		"Matt Zuba <matt.zuba@goodwillaz.org"
 description     "Kallithea Mercurial Server"
 author          "Matt Zuba <matt.zuba@goodwillaz.org"
 start on (local-filesystems and runlevel [2345])
 stop on runlevel [!2345]
 respawn
@@ @@ -16,11 +16,11 @@ env PIDFILE=/var/hg/kallithea/kallithea. @@
 env LOGFILE=/var/hg/kallithea/log/kallithea.log
 env APPINI=/var/hg/kallithea/production.ini
 env HOME=/var/hg
 env USER=hg
 env GROUP=hg
-exec /var/hg/.virtualenvs/kallithea/bin/paster serve --user=$USER --group=$GROUP --pid-file=$PIDFILE --log-file=$LOGFILE $APPINI
+exec /var/hg/.virtualenvs/kallithea/bin/gearbox serve --user=$USER --group=$GROUP --pid-file=$PIDFILE --log-file=$LOGFILE -c $APPINI
 post-stop script
-	rm -f $PIDFILE
+    rm -f $PIDFILE
 end script

init.d/supervisord.conf

➞

Show inline comments

@@ @@ -42,10 +42,10 @@ serverurl=http://127.0.0.1:9001 ; use an @@
 ; restart with supervisorctl restart kallithea:*
 [program:kallithea]
 numprocs = 1
 numprocs_start = 5000 # possible should match ports
 directory=/srv/kallithea
-command = /srv/kallithea/venv/bin/paster serve my.ini
+command = /srv/kallithea/venv/bin/gearbox serve -c my.ini
 process_name = %(program_name)s_%(process_num)04d
 redirect_stderr=true
 stdout_logfile=/%(here)s/kallithea.log
 redirect_stderr=true
 stdout_logfile=/%(here)s/kallithea.log

kallithea/__init__.py

➞

Show inline comments

@@ @@ -12,90 +12,52 @@ @@
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 """
 kallithea
 ~~~~~~~~~
 Kallithea, a web based repository management based on pylons
 versioning implementation: http://www.python.org/dev/peps/pep-0386/
 Kallithea, a web based repository management system.
 Versioning implementation: http://www.python.org/dev/peps/pep-0386/
 This file was forked by the Kallithea project in July 2014.
 Original author and date, and relevant copyright and licensing information is below:
 :created_on: Apr 9, 2010
 :author: marcink
 :copyright: (c) 2013 RhodeCode GmbH, (C) 2014 Bradley M. Kuhn, and others.
 :license: GPLv3, see LICENSE.md for more details.
 """
 import sys
 import platform
-VERSION = (0, 3, 7)
+VERSION = (0, 4, 0, 'rc2')
 BACKENDS = {
     'hg': 'Mercurial repository',
     'git': 'Git repository',
+}
 CELERY_ON = False
 CELERY_EAGER = False
 # link to config for pylons
 CONFIG = {}
 # Linked module for extensions
 EXTENSIONS = {}
 # BRAND controls internal references in database and config to the products
 # own name.
+#
 # NOTE: If you want compatibility with a database that was originally created
 #  for use with the RhodeCode software product, change BRAND to "rhodecode",
 #  either by editing here or by creating a new file:
 #  echo "BRAND = 'rhodecode'" > kallithea/brand.py
 BRAND = "kallithea"
 try:
-    from kallithea.brand import BRAND
+    import kallithea.brand
 except ImportError:
     pass
 # Prefix for the ui and settings table names
 DB_PREFIX = (BRAND + "_") if BRAND != "kallithea" else ""
 # Users.extern_type and .extern_name value for local users
 EXTERN_TYPE_INTERNAL = BRAND if BRAND != 'kallithea' else 'internal'
 # db_migrate_version.repository_id value, same as kallithea/lib/dbmigrate/migrate.cfg
 DB_MIGRATIONS = BRAND + "_db_migrations"
 else:
     assert False, 'Database rebranding is no longer supported; see README.'
 try:
     from kallithea.lib import get_current_revision
     _rev = get_current_revision(quiet=True)
     if _rev and len(VERSION) > 3:
         VERSION += (_rev[0],)
 except ImportError:
     pass
 __version__ = ('.'.join((str(each) for each in VERSION[:3])))
 __dbversion__ = 31  # defines current db version for migrations
 __version__ = '.'.join(str(each) for each in VERSION)
 __platform__ = platform.system()
 __license__ = 'GPLv3'
 __py_version__ = sys.version_info
 __author__ = "Various Authors"
 __url__ = 'https://kallithea-scm.org/'
 is_windows = __platform__ in ['Windows']
 is_unix = not is_windows
 if len(VERSION) > 3:
     __version__ += '.'+VERSION[3]
     if len(VERSION) > 4:
         __version__ += VERSION[4]
     else:
         __version__ += '0'
 # Hack for making the celery dependency kombu==1.5.1 compatible with Python
 # 2.7.11 which has https://hg.python.org/releases/2.7.11/rev/24bdc4940e81
 import uuid
 if not hasattr(uuid, '_uuid_generate_random'):
     uuid._uuid_generate_random = None

kallithea/alembic/env.py

➞

Show inline comments

@@ new file 100644 @@
 # -*- coding: utf-8 -*-
 # This program is free software: you can redistribute it and/or modify
 # it under the terms of the GNU General Public License as published by
 # the Free Software Foundation, either version 3 of the License, or
 # (at your option) any later version.
+#
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
+#
 # You should have received a copy of the GNU General Public License
 # along with this program.  If not, see <http://www.gnu.org/licenses/>.
 # Alembic migration environment (configuration).
 import logging
 from logging.config import fileConfig
 from alembic import context
 from sqlalchemy import engine_from_config, pool
 from kallithea.model import db
 # The alembic.config.Config object, which wraps the current .ini file.
 config = context.config
 # Default to use the main Kallithea database string in [app:main].
 # For advanced uses, this can be overridden by specifying an explicit
 # [alembic] sqlalchemy.url.
 database_url = (
     config.get_main_option('sqlalchemy.url') or
     config.get_section_option('app:main', 'sqlalchemy.url')
+)
 # Configure default logging for Alembic. (This can be overriden by the
 # config file, but usually isn't.)
 logging.getLogger('alembic').setLevel(logging.INFO)
 # Setup Python loggers based on the config file provided to the alembic
 # command. If we're being invoked via the Alembic API (presumably for
 # stamping during "kallithea-cli db-create"), config_file_name is not available,
 # and loggers are assumed to already have been configured.
 if config.config_file_name:
     fileConfig(config.config_file_name, disable_existing_loggers=False)
 def include_in_autogeneration(object, name, type, reflected, compare_to):
     """Filter changes subject to autogeneration of migrations. """
     # Don't include changes to sqlite_sequence.
     if type == 'table' and name == 'sqlite_sequence':
         return False
     return True
 def run_migrations_offline():
     """Run migrations in 'offline' (--sql) mode.
     This produces an SQL script instead of directly applying the changes.
     Some migrations may not run in offline mode.
     """
     context.configure(
         url=database_url,
         literal_binds=True,
+    )
     with context.begin_transaction():
         context.run_migrations()
 def run_migrations_online():
     """Run migrations in 'online' mode.
     Connects to the database and directly applies the necessary
     migrations.
     """
     cfg = config.get_section(config.config_ini_section)
     cfg['sqlalchemy.url'] = database_url
     connectable = engine_from_config(
         cfg,
         prefix='sqlalchemy.',
         poolclass=pool.NullPool)
     with connectable.connect() as connection:
         context.configure(
             connection=connection,
             # Support autogeneration of migration scripts based on "diff" between
             # current database schema and kallithea.model.db schema.
             target_metadata=db.Base.metadata,
             include_object=include_in_autogeneration,
             render_as_batch=True, # batch mode is needed for SQLite support
+        )
         with context.begin_transaction():
             context.run_migrations()
 if context.is_offline_mode():
     run_migrations_offline()
 else:
     run_migrations_online()

Changeset was too big and was cut off... Show full diff anyway

0 comments (0 inline, 0 general)