Mercurial > hg > orthanc-book
changeset 339:c0a3cd1cabff
Accessing code repositories
author | Sebastien Jodogne <s.jodogne@gmail.com> |
---|---|
date | Thu, 26 Mar 2020 13:32:08 +0100 |
parents | 93581ca92c6a |
children | b5741b354afa |
files | Sphinx/source/developers.rst Sphinx/source/developers/repositories.rst |
diffstat | 2 files changed, 147 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- a/Sphinx/source/developers.rst Thu Mar 19 09:46:02 2020 +0100 +++ b/Sphinx/source/developers.rst Thu Mar 26 13:32:08 2020 +0100 @@ -4,8 +4,10 @@ .. toctree:: :maxdepth: 1 + developers/repositories.rst developers/creating-plugins.rst developers/stone.rst developers/db-versioning.rst developers/implementation-notes.rst developers/coding-style.rst +
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Sphinx/source/developers/repositories.rst Thu Mar 26 13:32:08 2020 +0100 @@ -0,0 +1,145 @@ +.. _repositories: + +Accessing code repositories +=========================== + +.. contents:: + + +Context +------- + +The Orthanc server and most of its plugins are versioned using +`Mercurial <https://en.wikipedia.org/wiki/Mercurial>`__ on a +`self-hosted server <https://hg.orthanc-server.com/>`__. + +The Orthanc project started back in 2011, back in a time where +Mercurial and `Git <https://en.wikipedia.org/wiki/Git>`__ were equally +popular. Sébastien Jodogne, the original author of Orthanc, decided to +use Mercurial given the higher simplicity of its set of commands, and +given the fact it is safer to use for less experienced users. + +As pointed out on `Wikipedia +<https://en.wikipedia.org/wiki/Mercurial>`__, the *"Git vs. Mercurial +[debate] has become one of the holy wars of hacker culture."* We +certainly don't want to endure this debate in the context of the +Orthanc ecosystem. The fact is that a distributed revision-control +was needed for Orthanc, and that both Git and Mercurial have similar +set of features. + +If Orthanc were started in 2020, maybe we would have used Git, or +maybe not. But the Orthanc ecosystem is not about versioning +systems. We are entirely dedicated to lowering barriers to entry in +the field of medical imaging. As a consequence, the choice of +Mercurial should be considered as a part of the history, and we simply +ask people to accept it as a fact. + +Regarding the reason behind self-hosting, Orthanc was hosted on +`Google Code +<https://en.wikipedia.org/wiki/Google_Developers#Google_Code>`__ +between 2012 and 2015, until it was shutdown. In July 2015, Orthanc +was moved to `Bitbucket by Atlassian +<https://en.wikipedia.org/wiki/Bitbucket>`__. Unfortunately, in July +2019, Bitbucket announced that `Mercurial support would be dropped on +June 2020 +<https://bitbucket.org/blog/sunsetting-mercurial-support-in-bitbucket>`__, +forcing us to deal with another migration. + +We are of course grateful to Google and Atlassian for having hosted +Orthanc during 8 years. However, we cannot afford the cost of +periodically coping with hosting migrations. We prefer to have a +simpler environment, yet under our full control. As a consequence, +starting Q2 2020, Orthanc is hosted using the official ``hg serve`` +tool. + + +Accessing Mercurial +------------------- + +Read-only access +^^^^^^^^^^^^^^^^ + +Anybody has full read-only access to all of the Orthanc official +repositories, on our `self-hosted server +<https://hg.orthanc-server.com/>`__. + +.. highlight:: bash + +Locally cloning one of those Mercurial repositories (say, the main +``orthanc`` repository) is as simple as typing:: + + $ hg clone https://hg.orthanc-server.com/orthanc + + +Write access +^^^^^^^^^^^^ + +Only the core developers of Orthanc have direct write access to the +Orthanc repositories (through SSH). + + +Submitting code +^^^^^^^^^^^^^^^ + +We will of course be extremely grateful for receiving external code +contributions to the Orthanc repositories! + +However, one of the weaknesses of our self-hosted infrastructure is +that is does not support automation for `pull requests +<https://en.wikipedia.org/wiki/Distributed_version_control#Pull_requests>`__. +This section explains two ways of contributing: by submitting a patch, +or by providing a branch. + +Importantly, before any contribution can be accepted into the Orthanc +repositories, its author must sign a :ref:`CLA <cla>`. This allows +both the University Hospital of Liège and the Osimis company to act as +the official guardians of the whole Orthanc ecosystem. + + +Simple patch +............ + +.. highlight:: bash + +If you want to propose a simple contribution, the most direct way of +passing it on the Orthanc community is by creating a **simple patch**. + +First make sure to pull the latest version of the code repository, +then work on your modification in the ``default`` branch (i.e. in the +mainline code):: + + $ hg pull + $ hg up -c default + [...make your modifications...] + +Once your contribution is done, here is how to export a patch:: + + $ hg export -r default > /tmp/contribution.patch + +Once the patch is ready, you can send the ``/tmp/contribution.patch`` +file to the Orthanc community, e.g. by submitting it onto our official +`discussion group +<https://groups.google.com/forum/#!forum/orthanc-users>`__. The core +developers would reintegrate such a patch by typing the following +command on their side:: + + $ hg pull + $ hg up -c default + $ hg import /tmp/contribution.patch + + + +Submitting a set of changes +........................... + +Work-in-progress. + + + +Issue tracker +------------- + +This is work-in-progress. Orthanc will most probably move to the +`Roundup issue tracker +<https://en.wikipedia.org/wiki/Roundup_(issue_tracker)>`__ that is +notably used by the Python community.