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 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 handling of branches.

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 clonecommand 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 source repositories by

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

   The name thomas is an aribtrary name for the source 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