Git

The development of Bedymo and Dynlib is coordinated with the version control system git. git is a distributed version control system in that there is no central repository required, as would be for older systems like svn (subversion) or cvs. Any central repository is only central by convention.

Background

Common ideas behind all version control systems

All version control systems store the history of a set of files and directories in a repository, and are able to restore the file as it used to be in a previous version. In addition to the actual changes in the file(s) all systems also keep meta-information like the editing user, the date and time of the changes as well as a small description of the changes. The development of the project is tracked through commits, which creates and stores a new version or revision of all changed files.

Distributed version control

In a distributed version control system like git, there is no central repository. Every copy of the repository is technically equal, and is equally able to crate new versions. In a non-distributed version control system, only the central repository residing on a (publicly available) server is able to create new versions. Hence, you need connection to that server to be able to commit changes.

Advantages of distributed version control

Apart from the ability to track changes and view the entire history of the project also when offline (on a cruise, plane, conference or summer school with limited connectivity) the main advantage of distributed version control systems lies in the flexibility of the work flow, which can be easily setup to match the work groups inner workings: Often several people work on the same tool or model, but develop in different directions. Using the setup suggested below those people can still share bug fixes easily and merge there developments in the end.

Disadvantages of distributed version control

The added flexibility of a distributed system comes at the cost of loosing an intuitive way to address the different revisions. Using a central repository, one simply increases an internal revision counter, such that revision 765 supersedes revision 764. Without a central repository there is noone that could assign those kind of numbers. git uses the SHA1-hash of the commited files as an identifier for the revision, e.g. something like bbe0e301cb39b597a49b3819ccf8b0d08d817d2e. One need however only type the first couple of symbols until the identifier becomes unique. In this example taken from dynlib, bbe0 is enough to uniquely identify the revision. In addition one can always manually assign human-friendlier names such as gamma-0.4.2 for the above revision.

Usage for Bedymo and Dynlib

All instructions are shown here for dynlib. The setup for bedymo is indentical, so that you need only replace dynlib by bedymo to obtain the corresponding command for bedymo.

Obtaining dynlib

1. The official source code repository resides in Thomas' user directory. The clone command copies the entire repository into a dynlib folder in your current working directory.

   git clone /Data/gfi/users/tsp065/lib/dynlib.git

2. Change into the dynlib folder.

   cd dynlib

3. Compile the library.

   ./compile

Updating dynlib

1. The repository you cloned from is saved in the git configuration as origin designating your source repository. That's where the following command fetches updates from.

   git pull

2. Re-Compile the library.

   ./compile

Fetching updates by some other user

Let's assume the user tsp065 has coded some very interesting routines that have however not yet found thier way in the official respository.

1. Then, if tsp065 followed the instructions in the #Developing dynlib section, you can add Thomas' repository as one of your remote repositories by

   git remote add thomas /Data/gfi/users/tsp065/lib/dynlib_tsp065.git

   The name thomas is an aribtrary name for the remote repository.

2. Then you can fetch updates from Thomas' respository just like from the official one.

   git pull thomas

3. Re-Compile the library.

   ./compile

Developing dynlib

Locally saving your changes

Suppose you have edited some of the Fortran95 source code files, and want to save and share them.

1. Then first you have to commit the new version into your local development repository.

   git commit -a

   Give a sensible and brief description of your changes in the editor that is opened (automatically)

Setup of your personal publicly shared repository

1. Creating a bare repository for sharing.

   git clone . /Data/gfi/users/tsp065/lib/dynlib_<your-ID>.git

2. It is convenient to again setup a named remote repository.

   git remote add own /Data/gfi/users/tsp065/lib/dynlib_<your-ID>.git

Sharing your changes

1. Then you have to push your new version to a repository that other people can read.

   git push own

More information

1. The git book