Files
@ 805ec49152c9
Branch filter:
Location: kallithea/docs/upgrade.rst - annotation
805ec49152c9
3.1 KiB
text/prs.fallenstein.rst
simplehg: don't quiet Hg output for push
I want to be able to see informational messages from e.g. the Hg Bugzilla
extension.
Here's output without the patch. This is identical to the output produced if
the Bugzilla extension is disabled:
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: Repository size .hg:158.2 kB repo:0 B total:158.2 kB
remote: Last revision is now r324:6c03abbabb46
and with the patch:
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: Repository size .hg:158.2 kB repo:0 B total:158.2 kB
remote: Last revision is now r324:6c03abbabb46
remote: bug 3270 already knows about changeset 6c03abbabb46
The last line indicates that the Bugzilla bug text already contains an entry
for that changeset. It's produced by a call to self.ui.status() in the
extension.
I think the point here is that the deleted code is ensuring that the remote hg
(i.e. the Kallithea hg) always runs with the --quiet flag when receiving a
push. This seems an arbitrary decision to me, and one that removes potentially
useful information from the output. I believe this behaviour is different to
that seen by the user if pushing to hgweb (I've not tried it, but inspected the
hgweb source for setting quiet) and is certainly different to pushing over ssh.
I want to be able to see informational messages from e.g. the Hg Bugzilla
extension.
Here's output without the patch. This is identical to the output produced if
the Bugzilla extension is disabled:
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: Repository size .hg:158.2 kB repo:0 B total:158.2 kB
remote: Last revision is now r324:6c03abbabb46
and with the patch:
remote: adding changesets
remote: adding manifests
remote: adding file changes
remote: added 1 changesets with 1 changes to 1 files
remote: Repository size .hg:158.2 kB repo:0 B total:158.2 kB
remote: Last revision is now r324:6c03abbabb46
remote: bug 3270 already knows about changeset 6c03abbabb46
The last line indicates that the Bugzilla bug text already contains an entry
for that changeset. It's produced by a call to self.ui.status() in the
extension.
I think the point here is that the deleted code is ensuring that the remote hg
(i.e. the Kallithea hg) always runs with the --quiet flag when receiving a
push. This seems an arbitrary decision to me, and one that removes potentially
useful information from the output. I believe this behaviour is different to
that seen by the user if pushing to hgweb (I've not tried it, but inspected the
hgweb source for setting quiet) and is certainly different to pushing over ssh.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 | afd98d1f817e afd98d1f817e 17c9393e9645 afd98d1f817e afd98d1f817e afd98d1f817e 008d9c6f7c92 008d9c6f7c92 afd98d1f817e 8af52e1224ff 8b8edfc25856 008d9c6f7c92 8b8edfc25856 8b8edfc25856 e73a69cb98dc 8b8edfc25856 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 008d9c6f7c92 99ad9d0af1a3 e73a69cb98dc 008d9c6f7c92 8af52e1224ff 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc afd98d1f817e e73a69cb98dc afd98d1f817e afd98d1f817e afd98d1f817e e73a69cb98dc afd98d1f817e afd98d1f817e 008d9c6f7c92 8b8edfc25856 e73a69cb98dc 8b8edfc25856 e73a69cb98dc 8b8edfc25856 008d9c6f7c92 afd98d1f817e 053983a464e4 6fdc3b25bc7c 8330d5778ba3 8330d5778ba3 053983a464e4 8b8edfc25856 8330d5778ba3 8330d5778ba3 a040597b070b a040597b070b 8af52e1224ff a040597b070b 008d9c6f7c92 8b8edfc25856 8af52e1224ff 8b8edfc25856 9472a0150bf0 a040597b070b 2d4e1f5e854e 2d4e1f5e854e 2d4e1f5e854e 2d4e1f5e854e 2d4e1f5e854e e73a69cb98dc e73a69cb98dc 2d4e1f5e854e 8b8edfc25856 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 99ad9d0af1a3 008d9c6f7c92 008d9c6f7c92 008d9c6f7c92 e73a69cb98dc 008d9c6f7c92 8dfb265fc954 8dfb265fc954 8dfb265fc954 afd98d1f817e 8b8edfc25856 afd98d1f817e afd98d1f817e afd98d1f817e 008d9c6f7c92 | .. _upgrade:
=======
Upgrade
=======
Upgrading from PyPI (aka "Cheeseshop")
---------------------------------------
.. note::
Firstly, it is 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 1.3.6 to 1.4.0, the ``production.ini`` file would be
backed up to ``production.ini.1-3-6``.)
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 production.ini production.ini.{version}
Ensure that you are using the Python Virtual Environment that you'd originally
installed Kallithea in::
pip freeze
will list all packages installed in the current environment. If Kallithea
isn't listed, change virtual environments to your venv location::
source /opt/kallithea-venv/bin/activate
Once you have verified the environment you can upgrade ``Kallithea`` with::
easy_install -U kallithea
Or::
pip install --upgrade kallithea
Then run the following command from the installation directory::
paster make-config Kallithea production.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's recommended
that you re-check the content after the automerge.
.. note::
Please always make sure your .ini files are up to date. Often errors are
caused by missing params 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 production.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::
DB schema upgrade library has some limitations and can sometimes fail if you try to
upgrade from older major releases. In such case simply run upgrades sequentially, eg.
upgrading from 1.2.X to 1.5.X should be done like that: 1.2.X. > 1.3.X > 1.4.X > 1.5.X
You can always specify what version of Kallithea you want to install for example in pip
`pip install Kallithea==1.3.6`
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 /var/www/kallithea/production.ini
.. note::
If you're using Celery, make sure you restart all instances of it after
upgrade.
.. _virtualenv: http://pypi.python.org/pypi/virtualenv
.. _python: http://www.python.org/
.. _mercurial: http://mercurial.selenic.com/
.. _celery: http://celeryproject.org/
.. _rabbitmq: http://www.rabbitmq.com/
|