general.rst
157 lines
| 5.5 KiB
| text/x-rst
|
RstLexer
r1025 | .. _general: | |||
r2095 | ======================= | |||
|
r4192 | General Kallithea usage | ||
r1025 | ======================= | |||
Repository deleting | ||||
r1123 | ------------------- | |||
r1025 | ||||
|
r4955 | Currently 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 | ||||
|
r4962 | or access the repository. | ||
There is a special command for cleaning up such archived repos:: | ||||
r3335 | ||||
|
r4902 | paster cleanup-repos --older-than=30d my.ini | ||
r3335 | ||||
|
r4962 | This command scans for archived repositories that are older than | ||
30 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 | ||||
forks that are constantly being deleted, it is recommended that you run this | ||||
|
r4955 | command via crontab. | ||
r1025 | ||||
|
r4962 | 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. | ||||
r1025 | Follow current branch in file view | |||
r1123 | ---------------------------------- | |||
r1025 | ||||
In file view when this checkbox is checked the << and >> arrows will jump | ||||
|
r4955 | to changesets within the same branch currently being viewed. So for example | ||
if someone is viewing files in the ``beta`` branch and marks the `follow current branch` | ||||
checkbox the << and >> buttons will only show revisions for the `'beta`` branch. | ||||
r1025 | ||||
Compare view from changelog | ||||
r1123 | --------------------------- | |||
r1025 | ||||
|
r4955 | Checkboxes in the compare view allow users to view a combined compare | ||
view. You can only show the range between the first and last checkbox | ||||
(no cherry pick). Clicking more than one checkbox will activate a | ||||
link at the top saying ``Show selected changesets <from-rev> -> | ||||
<to-rev>``. Clicking this will activate the compare view. In this view | ||||
it is also possible to switch to combined compare. | ||||
r1025 | ||||
Compare view is also available from the journal on pushes having more than | ||||
|
r4955 | one changeset. | ||
r1025 | ||||
r1813 | Non changeable repository urls | |||
------------------------------ | ||||
|
r4955 | Due to the complicated nature of repository grouping, URLs of repositories | ||
can often change. | ||||
r1813 | ||||
example:: | ||||
r3224 | ||||
r1813 | #before | |||
http://server.com/repo_name | ||||
# after insertion to test_group group the url will be | ||||
http://server.com/test_group/repo_name | ||||
r3224 | ||||
r1813 | This can be an issue for build systems and any other hardcoded scripts, moving | |||
|
r4955 | a repository to a group leads to a need for changing external systems. To | ||
overcome this Kallithea introduces a non-changable replacement URL. It's | ||||
simply a repository ID prefixed with ``_``. The above URLs are also accessible as:: | ||||
r1813 | ||||
http://server.com/_<ID> | ||||
r3224 | ||||
|
r4955 | Since IDs are always the same, moving the repository will not affect | ||
such a URL. the ``_<ID>`` syntax can be used anywhere in the system so | ||||
URLs with ``repo_name`` for changelogs and files can be exchanged | ||||
with the ``_<ID>`` syntax. | ||||
r1813 | ||||
|
r4964 | E-mail notifications | ||
-------------------- | ||||
r1025 | ||||
|
r4964 | When the administrator correctly specified the e-mail settings in the Kallithea | ||
configuration file, Kallithea will send e-mails on user registration and when | ||||
|
r4955 | errors occur. | ||
r1025 | ||||
|
r4964 | Mails are also sent for comments on changesets. In this case, an e-mail is sent | ||
to the committer of the changeset (if known to Kallithea), to all reviewers of | ||||
the pull request (if applicable) and to all people mentioned in the comment | ||||
using @mention notation. | ||||
r2105 | ||||
r1025 | Trending source files | |||
r1123 | --------------------- | |||
r1025 | ||||
|
r4955 | Trending source files are calculated based on a pre-defined dict of known | ||
types and extensions. If you miss some extension or would like to scan some | ||||
custom files, it is possible to add new types in the ``LANGUAGES_EXTENSIONS_MAP`` dict | ||||
located in ``kallithea/lib/celerylib/tasks.py``. | ||||
r2706 | ||||
Cloning remote repositories | ||||
--------------------------- | ||||
|
r4955 | Kallithea has the ability to clone remote repos from given remote locations. | ||
Currently it supports the following options: | ||||
r2706 | ||||
- hg -> hg clone | ||||
- svn -> hg clone | ||||
- git -> git clone | ||||
|
r4955 | .. note:: svn -> hg cloning requires tge ``hgsubversion`` library to be installed. | ||
r2706 | ||||
If you need to clone repositories that are protected via basic auth, you | ||||
|
r4955 | might pass the url with stored credentials inside, e.g., | ||
``http://user:passw@remote.server/repo``, Kallithea will try to login and clone | ||||
using the given credentials. Please take note that they will be stored as | ||||
|
r4192 | plaintext inside the database. Kallithea will remove auth info when showing the | ||
r2706 | clone url in summary page. | |||
r3770 | ||||
|
r4963 | Specific features configurable in the Admin settings | ||
---------------------------------------------------- | ||||
r3770 | ||||
|
r4963 | 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. | ||||
r3770 | ||||
|
r4963 | Repository extra fields | ||
~~~~~~~~~~~~~~~~~~~~~~~ | ||||
r3777 | ||||
|
r4963 | In the `Visual` tab, there is an option `Use repository extra | ||
fields`, which allows to set custom fields for each repository in the system. | ||||
Each new field consists of 3 attributes: ``field key``, ``field label``, | ||||
``field description``. | ||||
r3939 | ||||
|
r4963 | 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. | ||||
r3770 | ||||
Meta-Tagging | ||||
~~~~~~~~~~~~ | ||||
|
r4963 | In the `Visual` tab, option `Stylify recognised meta tags` will cause Kallithea | ||
to turn certain meta-tags, detected in repository and repository group | ||||
descriptions, into colored tags. Currently recognised tags are:: | ||||
r3770 | ||||
[featured] | ||||
[stale] | ||||
[dead] | ||||
[lang => lang] | ||||
[license => License] | ||||
[requires => Repo] | ||||
[recommends => Repo] | ||||
[see => URI] | ||||