comparison docs/usage/general.rst @ 4955:4e6dfdb3fa01

docs: English and consistency corrections
author Michael V. DePalatis <mike@depalatis.net>
date Tue, 31 Mar 2015 22:15:38 +0200
parents 03bbd33bc084
children 35d560f0f842
comparison
equal deleted inserted replaced
4954:14f063657078 4955:4e6dfdb3fa01
6 6
7 7
8 Repository deleting 8 Repository deleting
9 ------------------- 9 -------------------
10 10
11 Currently when admin/owner deletes a repository, Kallithea does not physically 11 Currently when an admin or owner deletes a repository, Kallithea does
12 delete a repository from filesystem, it renames it in a special way so it's 12 not physically delete said repository from the filesystem, but instead
13 not possible to push,clone or access repository. It's worth a notice that, 13 renames it in a special way so that it is not possible to push, clone
14 even if someone will be given administrative access to Kallithea and will 14 or access repository. It is worth noting that even if someone will be
15 delete a repository You can easy restore such action by restoring `rm__<date>` 15 given administrative access to Kallithea and will delete a repository,
16 from the repository name, and internal repository storage (.hg/.git). There 16 you can easy restore such an action by removing ``rm__<date>`` from
17 is also a special command for cleaning such archived repos:: 17 the repository name. There is also a special command for cleaning such
18 archived repos::
18 19
19 paster cleanup-repos --older-than=30d my.ini 20 paster cleanup-repos --older-than=30d my.ini
20 21
21 This command will scan for archived repositories that are older than 30d, 22 This command will scan for archived repositories that are older than
22 display them and ask if you want to delete them (there's a --dont-ask flag also) 23 30 days, display them, and ask if you want to delete them (there is
23 If you host big amount of repositories with forks that are constantly deleted 24 a ``--dont-ask`` flag also) If you host a large amount of repositories with
24 it's recommended that you run such command via crontab. 25 forks that are constantly deleted it is recommended that you run such a
26 command via crontab.
25 27
26 Follow current branch in file view 28 Follow current branch in file view
27 ---------------------------------- 29 ----------------------------------
28 30
29 In file view when this checkbox is checked the << and >> arrows will jump 31 In file view when this checkbox is checked the << and >> arrows will jump
30 to changesets within the same branch currently viewing. So for example 32 to changesets within the same branch currently being viewed. So for example
31 if someone is viewing files at 'beta' branch and marks `follow current branch` 33 if someone is viewing files in the ``beta`` branch and marks the `follow current branch`
32 checkbox the << and >> buttons will only show him revisions for 'beta' branch 34 checkbox the << and >> buttons will only show revisions for the `'beta`` branch.
33 35
34 36
35 Compare view from changelog 37 Compare view from changelog
36 --------------------------- 38 ---------------------------
37 39
38 Checkboxes in compare view allow users to view combined compare view. You can 40 Checkboxes in the compare view allow users to view a combined compare
39 only show the range between the first and last checkbox (no cherry pick). 41 view. You can only show the range between the first and last checkbox
40 Clicking more than one checkbox will activate a link in top saying 42 (no cherry pick). Clicking more than one checkbox will activate a
41 `Show selected changesets <from-rev> -> <to-rev>` clicking this will bring 43 link at the top saying ``Show selected changesets <from-rev> ->
42 compare view. In this view also it's possible to switch to combined compare. 44 <to-rev>``. Clicking this will activate the compare view. In this view
45 it is also possible to switch to combined compare.
43 46
44 Compare view is also available from the journal on pushes having more than 47 Compare view is also available from the journal on pushes having more than
45 one changeset 48 one changeset.
46 49
47 50
48 Non changeable repository urls 51 Non changeable repository urls
49 ------------------------------ 52 ------------------------------
50 53
51 Due to complicated nature of repository grouping, often urls of repositories 54 Due to the complicated nature of repository grouping, URLs of repositories
52 can change. 55 can often change.
53 56
54 example:: 57 example::
55 58
56 #before 59 #before
57 http://server.com/repo_name 60 http://server.com/repo_name
58 # after insertion to test_group group the url will be 61 # after insertion to test_group group the url will be
59 http://server.com/test_group/repo_name 62 http://server.com/test_group/repo_name
60 63
61 This can be an issue for build systems and any other hardcoded scripts, moving 64 This can be an issue for build systems and any other hardcoded scripts, moving
62 repository to a group leads to a need for changing external systems. To 65 a repository to a group leads to a need for changing external systems. To
63 overcome this Kallithea introduces a non changable replacement url. It's 66 overcome this Kallithea introduces a non-changable replacement URL. It's
64 simply an repository ID prefixed with `_` above urls are also accessible as:: 67 simply a repository ID prefixed with ``_``. The above URLs are also accessible as::
65 68
66 http://server.com/_<ID> 69 http://server.com/_<ID>
67 70
68 Since ID are always the same moving the repository will not affect such url. 71 Since IDs are always the same, moving the repository will not affect
69 the _<ID> syntax can be used anywhere in the system so urls with repo_name 72 such a URL. the ``_<ID>`` syntax can be used anywhere in the system so
70 for changelogs, files and other can be exchanged with _<ID> syntax. 73 URLs with ``repo_name`` for changelogs and files can be exchanged
74 with the ``_<ID>`` syntax.
71 75
72 76
73 Mailing 77 Mailing
74 ------- 78 -------
75 79
76 When administrator will fill up the mailing settings in .ini files 80 When the administrator configures the mailing settings in .ini files
77 Kallithea will send mails on user registration, or when Kallithea errors occur 81 Kallithea will send mails on user registration, or when Kallithea
78 on errors the mails will have a detailed traceback of error. 82 errors occur.
79
80 83
81 Mails are also sent for code comments. If someone comments on a changeset 84 Mails are also sent for code comments. If someone comments on a changeset
82 mail is sent to all participants, the person who commited the changeset 85 mail is sent to all participants, the person who commited the changeset
83 (if present in Kallithea), and to all people mentioned with @mention system. 86 (if present in Kallithea), and to all people mentioned with the @mention system.
84 87
85 88
86 Trending source files 89 Trending source files
87 --------------------- 90 ---------------------
88 91
89 Trending source files are calculated based on pre defined dict of known 92 Trending source files are calculated based on a pre-defined dict of known
90 types and extensions. If You miss some extension or Would like to scan some 93 types and extensions. If you miss some extension or would like to scan some
91 custom files it's possible to add new types in `LANGUAGES_EXTENSIONS_MAP` dict 94 custom files, it is possible to add new types in the ``LANGUAGES_EXTENSIONS_MAP`` dict
92 located in `/kallithea/lib/celerylib/tasks.py` 95 located in ``kallithea/lib/celerylib/tasks.py``.
93 96
94 97
95 Cloning remote repositories 98 Cloning remote repositories
96 --------------------------- 99 ---------------------------
97 100
98 Kallithea has an ability to clone remote repos from given remote locations. 101 Kallithea has the ability to clone remote repos from given remote locations.
99 Currently it support following options: 102 Currently it supports the following options:
100 103
101 - hg -> hg clone 104 - hg -> hg clone
102 - svn -> hg clone 105 - svn -> hg clone
103 - git -> git clone 106 - git -> git clone
104 107
105 108
106 .. note:: 109 .. note:: svn -> hg cloning requires tge ``hgsubversion`` library to be installed.
107
108 - *`svn -> hg` cloning requires `hgsubversion` library to be installed.*
109 110
110 If you need to clone repositories that are protected via basic auth, you 111 If you need to clone repositories that are protected via basic auth, you
111 might pass the url with stored credentials inside eg. 112 might pass the url with stored credentials inside, e.g.,
112 `http://user:passw@remote.server/repo`, Kallithea will try to login and clone 113 ``http://user:passw@remote.server/repo``, Kallithea will try to login and clone
113 using given credentials. Please take a note that they will be stored as 114 using the given credentials. Please take note that they will be stored as
114 plaintext inside the database. Kallithea will remove auth info when showing the 115 plaintext inside the database. Kallithea will remove auth info when showing the
115 clone url in summary page. 116 clone url in summary page.
116 117
117 118
118 119
119 Visual settings in admin pannel 120 Visual settings in admin pannel
120 ------------------------------- 121 -------------------------------
121 122
122 123
123 Visualisation settings in Kallithea settings view are extra customizations 124 Visualisation settings in Kallithea settings view are extra customizations
124 of server behavior. There are 3 main section in the settings. 125 of server behavior. There are 3 main sections in the settings.
125 126
126 General 127 General
127 ~~~~~~~ 128 ~~~~~~~
128 129
129 `Use repository extra fields` option allows to set a custom fields for each 130 The `Use repository extra fields` option allows to set a custom fields
130 repository in the system. Each new field consists of 3 attributes `field key`, 131 for each repository in the system. Each new field consists of 3
131 `field label`, `field description`. Example usage of such fields would be to 132 attributes: ``field key``, ``field label``, ``field
132 define company specific information into repositories eg. defining repo_manager 133 description``. Example usage of such fields would be to define company
133 key that would add give info about a manager of each repository. There's no 134 specific information into repositories, e.g., defining a
134 limit for adding custom fields. Newly created fields are accessible via API. 135 ``repo_manager`` key that would give info about a manager of each
136 repository. There's no limit for adding custom fields. Newly created
137 fields are accessible via API.
135 138
136 `Show Kallithea version` option toggles displaying exact Kallithea version in 139 The `Show Kallithea version` option toggles displaying the exact
137 the footer 140 Kallithea version in the footer
138 141
139 142
140 Dashboard items 143 Dashboard items
141 ~~~~~~~~~~~~~~~ 144 ~~~~~~~~~~~~~~~
142 145
143 Number if items in main page dashboard before pagination is displayed 146 Number of items in main page dashboard before pagination is displayed.
144 147
145 148
146 Icons 149 Icons
147 ~~~~~ 150 ~~~~~
148 151