UPGRADING.rst 20 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645646647648649650651652653654655656657658659660661662663664665666667668669670671672673674675676677678679680681682683684685686687688689690691692693694695696697698699700701702703704705706707708709710711712713714715716717718719720721722723724725726727728729730731732733734735736737738739740741742743744745746747748749750751752753754755756757758759760761762763764765766767768769770771772773774775776777778779780781782783784785786787788789
  1. Upgrading Pagure
  2. ================
  3. From 5.7 to 5.8
  4. ---------------
  5. The 5.8 release does not contain any database schema changes nor changes in the
  6. configuration keys.
  7. From 5.6 to 5.7
  8. ---------------
  9. The 5.7 release does not contain any database schema changes nor changes in the
  10. configuration keys.
  11. From 5.5 to 5.6
  12. ---------------
  13. The 5.6 release contains a database schema updates, so:
  14. * Update the data schema using alembic: ``alembic upgrade head``
  15. (As usual, do your backups before).
  16. New configuration key added:
  17. * CSP_HEADERS
  18. From 5.4 to 5.5
  19. ---------------
  20. The 5.5 release contains a database schema updates, so:
  21. * Update the data schema using alembic: ``alembic upgrade head``
  22. New configuration key added:
  23. * GIT_HOOK_DB_RO
  24. From 5.3.x to 5.4
  25. -----------------
  26. The 5.4 release does not contain any database schema changes, nor any new
  27. configuration key.
  28. From 5.2 to 5.3
  29. ---------------
  30. The 5.3 release contains a database schema updates, so:
  31. * Update the data schema using alembic: ``alembic upgrade head``
  32. (As usual, do your backups before).
  33. While working on pagure 5.3, we found that the version of python werkzeug
  34. available in CentOS 7 is too old and makes some of pagure's tests fail. We
  35. recomment it to be upgrade to at least 0.9.6.
  36. New configuration keys have been added:
  37. * ENABLE_TICKETS_NAMESPACE
  38. * FEDORA_MESSAGING_NOTIFICATIONS
  39. * SYNTAX_ALIAS_OVERRIDES
  40. * ALWAYS_STOMP_ON_COMMITS
  41. * ALWAYS_MQTT_ON_COMMITS
  42. * MQTT_TOPIC_PREFIX
  43. From 5.1.x to 5.2
  44. -----------------
  45. The 5.2 release contains a database schema updates, so:
  46. * Update the data schema using alembic: ``alembic upgrade head``
  47. (As usual, do your backups before).
  48. If you run into issues with the ``hook_mirror``, see the upgrade notes for
  49. the release 5.1.4 below.
  50. Note that the minimal version of pygit2 has been bumped to: 0.26.0
  51. New configuration keys have been added:
  52. * MQTT_NOTIFICATIONS
  53. * MQTT_HOST
  54. * MQTT_PORT
  55. * MQTT_USERNAME
  56. * MQTT_PASSWORD
  57. * MQTT_CA_CERTS
  58. * MQTT_CERTFILE
  59. * MQTT_KEYFILE
  60. * MQTT_CERT_REQS
  61. * MQTT_TLS_VERSION
  62. * MQTT_CIPHERS
  63. * DISABLE_MIRROR_IN
  64. * SSH_ADMIN_TOKEN
  65. * GIT_GARBAGE_COLLECT
  66. * DISABLE_REMOTE_PR
  67. * ADMIN_EMAIL
  68. * LOG_ALL_COMMITS
  69. * ARCHIVE_FOLDER
  70. One configuration key changes its default structure:
  71. * TRIGGER_CI
  72. Changes in dependencies:
  73. * Mimimal version of pygit2 version bumped to: 0.26.0
  74. * Minimal version of openssh set to: 7.4
  75. From 5.1 to 5.1.4
  76. -----------------
  77. In the development of 5.1.4 it was found out that the alembic migration
  78. ``ba538b2648b7`` that creates the ``hook_mirror`` table was incomplete.
  79. If you created that table via alembic, you will likely want to re-run it. Beware
  80. that applying the following commands will destroy any data you have in this
  81. table.
  82. * Mark the database to this migration::
  83. alembic stamp ba538b2648b7
  84. * Remove the ``hook_mirror`` table so it can be re-generated::
  85. alembic downgrade -1
  86. * Re-run that single migration::
  87. alembic upgrade +1
  88. * Marking the database to the last current migration (as of 5.1.4)::
  89. alembic stamp f16ab75e4d32
  90. Again, any project that tried to setup the mirroring feature in pagure will need
  91. to be reconfigured.
  92. Another option (that will prevent loosing any data in this table) is to
  93. adjust the table manually using these SQL queries:
  94. ::
  95. ALTER TABLE hook_mirror ADD COLUMN 'public_key' TEXT;
  96. ALTER TABLE hook_mirror ADD COLUMN 'target' TEXT;
  97. ALTER TABLE hook_mirror ADD COLUMN 'last_log' TEXT;
  98. From 5.x to 5.1
  99. ---------------
  100. The 5.1 release contains a database schema updates, so:
  101. * Update the data schema using alembic: ``alembic upgrade head``
  102. (As usual, do your backups before).
  103. New configuration keys added:
  104. * ALLOW_ADMIN_IGNORE_EXISTING_REPOS
  105. * ALLOW_HTTP_PULL_PUSH
  106. * ALLOW_HTTP_PUSH
  107. * HTTP_REPO_ACCESS_GITOLITE
  108. From 5.0 to 5.0.1
  109. -----------------
  110. The 5.0 release was missing a database schema migration to add the
  111. ``hook_mirror`` table. This alembic migration has been added, so if you have
  112. note update to 5.0, you will want to update your database schema using:
  113. ``alembic upgrade head``. If you went around this issue by running the
  114. ``pagure_createdb.py`` script, you can mark you database schema up to date using
  115. ``alembic stamp ba538b2648b7``.
  116. From 4.x to 5.0
  117. ---------------
  118. The release 5.0 brings some changes to the database schema.
  119. * Update the data schema using alembic: ``alembic upgrade head``
  120. New configuration keys added:
  121. * PR_TARGET_MATCHING_BRANCH
  122. * EMAIL_ON_WATCHCOMMITS
  123. * THEME
  124. * GIT_AUTH_BACKEND (replacing GITOLITE_BACKEND, backward compatibility kept for
  125. now)
  126. * REPOSPANNER_PSEUDO_FOLDER
  127. * REPOSPANNER_NEW_REPO
  128. * REPOSPANNER_NEW_REPO_ADMIN_OVERRIDE
  129. * REPOSPANNER_NEW_FORK
  130. * REPOSPANNER_ADMIN_MIGRATION
  131. * REPOSPANNER_REGIONS
  132. * SSH_KEYS_USERNAME_LOOKUP
  133. * SSH_KEYS_USERNAME_EXPECT
  134. * SSH_KEYS_OPTIONS
  135. Configuration deprecated:
  136. * BOOTSTRAP_URLS_CSS
  137. * BOOTSTRAP_URLS_JS
  138. * FILE_SIZE_HIGHLIGHT
  139. * HTML_TITLE
  140. * GITOLITE_BACKEND
  141. Note: Some configuration keys changed their default value:
  142. * LOGGING
  143. * PRIVATE_PROJECTS
  144. * EMAIL_ERROR
  145. * FROM_EMAIL
  146. * DOMAIN_EMAIL_NOTIFICATIONS
  147. * APP_URL
  148. * DOC_APP_URL
  149. * GIT_URL_SSH
  150. * GIT_URL_GIT
  151. * FEDMSG_NOTIFICATIONS
  152. * PAGURE_AUTH
  153. New dependencies:
  154. * trololio (replaces trollius that is no longer a direct dependency)
  155. From 3.x to 4.0
  156. ---------------
  157. The release 4.0 brings some changes to the database schema.
  158. * Update the data schema using alembic: ``alembic upgrade head``
  159. New configuration keys added:
  160. * EMAIL_ON_WATCHCOMMITS
  161. * ALWAYS_FEDMSG_ON_COMMITS
  162. * SESSION_TYPE
  163. * PROJECT_TEMPLATE_PATH
  164. * FORK_TEMPLATE_PATH
  165. From 3.13 to 3.13.1
  166. -------------------
  167. The release 3.13.1 brings one change to the database schema to remove a database
  168. constraint (pull_requests_check in the pull_requests table) that is not only no
  169. longer needed but even blocking now.
  170. * Update the data schema using alembic: ``alembic upgrade head``
  171. From 3.12 to 3.13
  172. -----------------
  173. The release 3.13 brings some features and bug fixes but does not have any
  174. changes made to the database schema or new configuration keys. Update should be
  175. straight forward.
  176. From 3.11 to 3.12
  177. -----------------
  178. The release 3.12 brings some changes to the database schema.
  179. * Update the data schema using alembic: ``alembic upgrade head``
  180. Note that this release bring support for `OpenID
  181. Connect<https://en.wikipedia.org/wiki/OpenID_Connect>`_ authentication, meaning
  182. pagure can now be deployed with authentication coming from, for example, google.
  183. This brings a number of new configuration keys:
  184. * OIDC_CLIENT_SECRETS
  185. * OIDC_ID_TOKEN_COOKIE_SECURE
  186. * OIDC_SCOPES
  187. * OIDC_PAGURE_EMAIL
  188. * OIDC_PAGURE_FULLNAME
  189. * OIDC_PAGURE_USERNAME
  190. * OIDC_PAGURE_SSH_KEY
  191. * OIDC_PAGURE_GROUPS
  192. * OIDC_PAGURE_USERNAME_FALLBACK
  193. From 3.10 to 3.11
  194. -----------------
  195. The release 3.11 brings some changes to the database schema.
  196. * Update the data schema using alembic: ``alembic upgrade head``
  197. In addition, if you are deploying pagure with fedmsg support you had to set
  198. fedmsg to the
  199. `active <http://www.fedmsg.com/en/stable/publishing/#publishing-through-a-relay>`_
  200. mode for the workers to be able to send fedmsg messages. This is now the
  201. default and forced configuration.
  202. New API acls:
  203. * commit_flag
  204. * pull_request_subscribe
  205. From 3.9 to 3.10
  206. ----------------
  207. The release 3.10 brings some changes to the database schema.
  208. * Update the data schema using alembic: ``alembic upgrade head``
  209. From 3.8 to 3.9
  210. ---------------
  211. This release brings a number of bug fixes and features but does not require
  212. any special precaution when upgrading.
  213. From 3.7 to 3.8
  214. ---------------
  215. The release 3.8 brings some changes to the database schema.
  216. * Update the data schema using alembic: ``alembic upgrade head``
  217. New configuration keys added:
  218. * PROJECT_NAME_REGEX
  219. From 3.6 to 3.7
  220. ---------------
  221. The release 3.7 brings some changes to the database schema.
  222. * Update the data schema using alembic: ``alembic upgrade head``
  223. New configuration keys added:
  224. * ENABLE_DEL_FORKS
  225. * ENABLE_UI_NEW_PROJECTS
  226. From 3.5 to 3.6
  227. ---------------
  228. New configuration keys added:
  229. * GITOLITE_CELERY_QUEUE
  230. From 3.4 to 3.5
  231. ---------------
  232. New configuration keys added:
  233. * USER_ACLS
  234. * CASE_SENSITIVE
  235. * HTML_TITLE
  236. From 3.3 to 3.4
  237. ---------------
  238. New configuration keys added:
  239. * DEPLOY_KEY
  240. * LOCAL_SSH_KEY
  241. * ALLOW_DELETE_BRANCH
  242. From 3.2 to 3.3
  243. ---------------
  244. [SECURITY FIX]: The 3.3 release contains an important security fix.
  245. If you are using the private project feature of pagure, the gitolite
  246. configuration generated was still granting access to the private projects. This
  247. made the private projects visible and accessible.
  248. After updating to 3.3, ensure your gitolite configuration gets re-generated
  249. (pagure-admin refresh-gitolite can help you with this).
  250. The 3.3 release brings some adjustments to the database schema.
  251. * Update the database schema using alembic: ``alembic upgrade head``
  252. From 3.1 to 3.2
  253. ---------------
  254. While not being a bug fix, this release has no database schema changes.
  255. However, this release breaks the plugin interface for auth introduced in 3.1 and
  256. changed in 3.1. If you are using pagure-dist-git, make sure to upgrade to at
  257. least 0.4. This interface will be considered stable in 3.4 and announced as
  258. such.
  259. From 3.0 to 3.1
  260. ---------------
  261. While not being a bug fix, this release has no database schema changes.
  262. However, this release breaks the plugin interface for auth introduced in 3.0. If
  263. you are using pagure-dist-git, make sure to upgrade to at least 0.3.
  264. From 2.15 to 3.0
  265. ----------------
  266. The 3.0 version was released with some major re-architecturing. The interaction
  267. with the backend git repo (being the main source repo or the tickets or requests
  268. repos) are now done by a worker that is triggered via a message queue.
  269. This communication is done using `celery <http://www.celeryproject.org/>`_ and
  270. via one of the message queue celery supports (pagure currently defaulting to
  271. `redis <https://redis.io/>`_.
  272. So to get pagure 3.0 running, you will need to get your own message queue (such
  273. as redis) up running and configured in pagure's configuration.
  274. This major version bump has also been an opportunity to rename all the services
  275. to use the same naming schema of pagure-<service>.
  276. The rename is as such:
  277. +------------------+-----------------+
  278. | In 2.x | From 3.0 |
  279. +==================+=================+
  280. | pagure-ci | pagure-ci |
  281. +------------------+-----------------+
  282. | ev-server | pagure-ev |
  283. +------------------+-----------------+
  284. | pagure-loadjson | pagure-loadjson |
  285. +------------------+-----------------+
  286. | pagure-logcom | pagure-logcom |
  287. +------------------+-----------------+
  288. | milters | pagure-milters |
  289. +------------------+-----------------+
  290. | webhook-server | pagure-webhook |
  291. +------------------+-----------------+
  292. | | pagure-worker |
  293. +------------------+-----------------+
  294. .. note:: This last service is the service mentioned above and it is part of
  295. pagure core, not optional unlike the other services in this table.
  296. This release also introduces some new configuration keys:
  297. - ``CELERY_CONFIG`` defaults to ``{}``
  298. - ``ATTACHMENTS_FOLDER``, to be configured
  299. - ``GITOLITE_BACKEND`` defaults to ``gitolite3``, deprecates ``GITOLITE_VERSION``
  300. - ``EXTERNAL_COMMITTER`` defaults to ``{}``
  301. - ``REQUIRED_GROUPS`` defaults to ``{}``
  302. This version also introduces a few database changes, so you will need to update
  303. the database schema using alembic: ``alembic upgrade head``.
  304. From 2.14 to 2.15
  305. -----------------
  306. The 2.15 release brings some adjustments to the database scheme.
  307. * Update the database schame using alembic: ``alembic upgrade head``
  308. From 2.13 to 2.14
  309. -----------------
  310. The 2.14 release brings some adjustments to the database scheme.
  311. * Update the database schame using alembic: ``alembic upgrade head``
  312. From 2.12 to 2.13
  313. -----------------
  314. The 2.13 release brings some adjustments to the database scheme.
  315. * Update the database schame using alembic: ``alembic upgrade head``
  316. From 2.11 to 2.12
  317. -----------------
  318. From this release on, we will have alembic migration script for new table
  319. creation, so there will no longer be a need to use ``createdb.py``
  320. The 2.12 release brings some adjustments to the database scheme.
  321. * Update the database schame using alembic: ``alembic upgrade head``
  322. From 2.10 to 2.11
  323. -----------------
  324. The 2.10 releases brings some adjustments to the database scheme.
  325. * Create the new DB tables and the new status field using the ``createdb.py``
  326. script.
  327. * Update the database schame using alembic: ``alembic upgrade head``
  328. From 2.9 to 2.10
  329. ----------------
  330. The 2.10 releases brings some little changes to the database scheme.
  331. Therefore when upgrading to 2.10, you will have to:
  332. * Update the database schame using alembic: ``alembic upgrade head``
  333. From 2.8 to 2.9
  334. ---------------
  335. The 2.9 releases brings some adjustments to the database scheme.
  336. * Create the new DB tables and the new status field using the ``createdb.py``
  337. script.
  338. * Update the database schame using alembic: ``alembic upgrade head``
  339. If you are interested in loading your local data into the ``pagure_logs`` table
  340. that this new release adds (data which is then displayed in the calendar heatmap
  341. on the user's page), you can find two utility scripts in
  342. https://pagure.io/pagure-utility that will help you to do that. They are:
  343. * fill_logs_from_db - Based on the data present in the database, this script
  344. fills the ``pagure_logs`` table (this will add: new ticket, new comment, new
  345. PR, closing a PR or a ticket and so on).
  346. * fill_logs_from_gits - By going through all the git repo hosted in your pagure
  347. instance, it will log who did what when.
  348. From 2.7 to 2.8
  349. ---------------
  350. 2.8 brings a little change to the database scheme.
  351. Therefore when upgrading to from 2.7 to 2.8, you will have to:
  352. * Update the database schame using alembic: ``alembic upgrade head``
  353. From 2.6 to 2.7
  354. ---------------
  355. 2.7 adds new tables as well as changes some of the existing ones.
  356. Therefore when upgrading to 2.7, you will have to:
  357. * Create the new DB tables and the new status field using the ``createdb.py``
  358. script.
  359. * Update the database schame using alembic, one of the upgrade will require
  360. access to pagure's configuration file, which should thus be passed onto the
  361. command via an environment variable:
  362. ``PAGURE_CONFIG=/path/to/pagure.cf alembic upgrade head``
  363. This release also brings a new configuration key:
  364. * ``INSTANCE_NAME`` used in the welcome screen shown upon first login (only with
  365. FAS and OpenID auth) to describe the instance
  366. The API has also been upgraded to a version ``0.8`` due to the changes (backward
  367. compatible) made to support the introduction of `close_status` to issues.
  368. From 2.5 to 2.6
  369. ---------------
  370. 2.6 brings quite a few changes and some of them impacting the database scheme.
  371. Therefore when upgrading from 2.4 to 2.6, you will have to:
  372. * Update the database schame using alembic: ``alembic upgrade head``
  373. From 2.4 to 2.5
  374. ---------------
  375. 2.5 brings quite a few changes and some of them impacting the database scheme.
  376. Therefore when upgrading from 2.4 to 2.5, you will have to:
  377. * Update the database schame using alembic: ``alembic upgrade head``
  378. From 2.3 to 2.4
  379. ---------------
  380. 2.4 brings quite a few changes and some of them impacting the database scheme.
  381. Therefore when upgrading from 2.3.x to 2.4, you will have to:
  382. * Update the database schame using alembic: ``alembic upgrade head``
  383. This update also brings some new configuration keys:
  384. * ``VIRUS_SCAN_ATTACHMENTS`` allows turning on or off checking attachments for
  385. virus using clamav. This requires pyclamd but is entirely optional (and off by
  386. default)
  387. * ``PAGURE_CI_SERVICES`` allows specifying with which CI (Continuous
  388. Integration) services this pagure instance can integrate with. Currently, only
  389. `Jenkins` is supported, but this configuration key defaults to ``None``.
  390. From 2.2 to 2.3
  391. ---------------
  392. 2.3 brings a few changes impacting the database scheme, including a new
  393. `duplicate` status for tickets, a feature allowing one to `watch` or
  394. `unwatch` a project and notifications on tickets as exist on pull-requests.
  395. Therefore, when upgrading from 2.2.x to 2.3, you will have to :
  396. * Create the new DB tables and the new status field using the ``createdb.py`` script.
  397. * Update the database schame using alembic: ``alembic upgrade head``
  398. This update also brings a new configuration key:
  399. * ``PAGURE_ADMIN_USERS`` allows to mark some users as instance-wide admins, giving
  400. them full access to every projects, private or not. This feature can then be
  401. used as a way to clean spams.
  402. * ``SMTP_PORT`` allows to specify the port to use when contacting the SMTP
  403. server
  404. * ``SMTP_SSL`` allows to specify whether to use SSL when contacting the SMTP
  405. server
  406. * ``SMTP_USERNAME`` and ``SMTP_PASSWORD`` if provided together allow to contact
  407. an SMTP requiring authentication.
  408. In this update is also added the script ``api_key_expire_mail.py`` meant to be
  409. run by a daily cron job and warning users when their API token is nearing its
  410. expiration date.
  411. 2.2.2
  412. -----
  413. Release 2.2.2 contains an important security fix, blocking a source of XSS
  414. attack.
  415. From 2.1 to 2.2
  416. ---------------
  417. 2.2 brings a number of bug fixes and a few improvements.
  418. One of the major changes impacts the databases where we must change some of the
  419. table so that the foreign key cascade on delete (fixes deleting a project when a
  420. few plugins were activated).
  421. When upgrading for 2.1 to 2.2 all you will have to do is:
  422. * Update the database scheme using alembic: ``alembic upgrade head``
  423. .. note:: If you run another database system than PostgreSQL the alembic
  424. revision ``317a285e04a8_delete_hooks.py`` will require adjustment as the
  425. foreign key constraints are named and the names are driver dependant.
  426. From 2.0 to 2.1
  427. ---------------
  428. 2.1 brings its usual flow of improvements and bug fixes.
  429. When upgrading from 2.0.x to 2.1 all you will have to:
  430. * Update the database schame using alembic: ``alembic upgrade head``
  431. From 1.x to 2.0
  432. ---------------
  433. As the version change indicates, 2.0 brings quite a number of changes,
  434. including some that are not backward compatible.
  435. When upgrading to 2.0 you will have to:
  436. * Update the database schema using alembic: ``alembic upgrade head``
  437. * Create the new DB tables so that the new plugins work using the
  438. ``createdb.py`` script
  439. * Move the forks git repo
  440. Forked git repos are now located under the same folder as the regular git
  441. repos, just under a ``forks/`` subfolder.
  442. So the structure changes from: ::
  443. repos/
  444. ├── foo.git
  445. └── bar.git
  446. forks/
  447. ├── patrick/
  448. │  ├── test.git
  449. │  └── ipsilon.git
  450. └── pingou/
  451. ├── foo.git
  452. └── bar.git
  453. to: ::
  454. repos/
  455. ├── foo.git
  456. ├── bar.git
  457. └── forks/
  458. ├── patrick/
  459. │  ├── test.git
  460. │  └── ipsilon.git
  461. └── pingou/
  462. ├── foo.git
  463. └── bar.git
  464. So the entire ``forks`` folder is moved under the ``repos`` folder where
  465. the other repositories are, containing the sources of the projects.
  466. Git repos for ``tickets``, ``requests`` and ``docs`` will be trickier to
  467. move as the structure changes from: ::
  468. tickets/
  469. ├── foo.git
  470. ├── bar.git
  471. ├── patrick/
  472. │  ├── test.git
  473. │  └── ipsilon.git
  474. └── pingou/
  475. ├── foo.git
  476. └── bar.git
  477. to: ::
  478. tickets/
  479. ├── foo.git
  480. ├── bar.git
  481. └── forks/
  482. ├── patrick/
  483. │  ├── test.git
  484. │  └── ipsilon.git
  485. └── pingou/
  486. ├── foo.git
  487. └── bar.git
  488. Same for the ``requests`` and the ``docs`` git repos.
  489. As you can see in the ``tickets``, ``requests`` and ``docs`` folders there
  490. are two types of folders, git repos which are folder with a name ending
  491. with ``.git``, and folder corresponding to usernames. These last ones are
  492. the ones to be moved into a subfolder ``forks/``.
  493. This can be done using something like: ::
  494. mkdir forks
  495. for i in `ls -1 |grep -v '\.git'`; do mv $i forks/; done
  496. * Re-generate the gitolite configuration.
  497. This can be done via the ``Re-generate gitolite ACLs file`` button in the
  498. admin page.
  499. * Keep URLs backward compatible
  500. The support of pseudo-namespace in pagure 2.0 has required some changes
  501. to the URL schema:
  502. https://pagure.io/pagure/053d8cc95fcd50c23a8b0a7f70e55f8d1cc7aebb
  503. became:
  504. https://pagure.io/pagure/c/053d8cc95fcd50c23a8b0a7f70e55f8d1cc7aebb
  505. (Note the added /c/ in it)
  506. We introduced a backward compatibility fix for this.
  507. This fix is however *disabled* by default so if you wish to keep the URLs
  508. valid, you will need to adjust you configuration file to include: ::
  509. OLD_VIEW_COMMIT_ENABLED = True