Documentation

Main Page -> Documentation

Mailing lists and collaborative tools

• Project web page: has to come
• General mailing list: pCT@uib.no
• Slack project

Software installation

• ROOT installation
• Geant 4 installation
• Gate installation
• FLUKA installation

Software repository

We use the gitlab server hosted by IT of University of Bergen. We start with a repository per work package (wp). As there is overlap in terms of software, this structure might change in the future. Log in with your UiB account, then the administrators will give you access to the pCT group. If you don't have an account yet, get in contact with the group over the general channels. There might be an admin mailing list later.

• UiB gitlab web interface.

Further information:

• Gitlab basics
• Gitlab workflow

Development workflow

Every logged-in user can access the main repository, however only a small group of administrators has write access. To contribute, a user creates a fork from the repository. This is a copy where a single developer or a group of developers have full access.

The main repository has the following branches:

• production: the latest production code, in this branch we have release tags
• master: the latest stable release
• dev: the development branch

In addition to those main branches there can be feature branches where development happens detached from the main branches. A feature branch is based on the dev branch and has a limited lifetime.

Creating a project fork

A project fork is a copy of the original repository where a user or a group of users has/have full control. All development in our project is carried out in the individual forks. Branches of project forks are merged back into the main repository by merge requests, preferably via fast forward merges. That requires developers to rebase project forks to the main repository and resolve all conflicts before requesting a merge.

How to fork a project

Making local development copy

Clone directly from your development fork, replace user and wpn (e.g. wp7) appropriately. Note: the gitlab offers two modes for the link to be cloned, you can choose ssh (default setting) or https. If you can not clone with the proposed default link, try option https://.

   git clone https://user@gitlab.uib.no/user/wpn.git

This repository will get the name origin in your local clone.

If you have cloned already from the main repository, the upstream link can be changed as follows

   cd <reponame>
   git remote set-url origin https://user@gitlab.uib.no/user/wpn.git

Pushing to development fork

Once you have added commits to e.g. the dev branch, those commits can be pushed upstream to the fork.

   git push origin dev

Pull/Merge request

All updates to the main repository are made via merge requests (github refers to them as pull requests). A merge request requires the code update to be in a mergable branch in a development fork.

Coming soon: HOWTO

Importing an external package

The project will use a couple of external packages which are hosted in a different master repository. Copies of such external packages can be added to the gitlab server under our project group to provide a consistent package.

Here is a proposed workflow for importing a package which is already hosted in git.

1. Create new repository in the pCT group or ask for creation, lets call it newPackage
2. Fork the repository to your user space
3. Clone the package you want to import

    git clone <some_external_link> newPackage # we give it the new name

    cd newPackage

4. Redirect upstream URL to the fork in your gitlab user space

    git remote set-url origin https://user@gitlab.uib.no/user/newPackage.git

5. Now make a forced push (option -f) to import the repository to your fork

    git push -f origin

6. Follow the instructions Pull/Merge request