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