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.
- 1 Background
- 2 Usage for Bedymo and Dynlib
- 3 Developing Bedymo and Dynlib
- 4 More information
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.
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.
- 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
- Change into the dynlib folder.
- Compile the library.
- The repository you cloned from is saved in the git configuration as
origindesignating your source repository. That's where the following command fetches updates from.
- Re-Compile the library.
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.
- Then, if
tsp065followed 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
thomasis an aribtrary name for the remote repository.
- Then you can fetch updates from Thomas' respository just like from the official one.
git pull thomas
- Re-Compile the library.
Developing Bedymo and Dynlib
Locally saving your changes
Suppose you have edited some of the Fortran95 source code files, and want to save and share them.
- 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
- Creating a bare repository for sharing.
git clone --bare . /Data/gfi/users/tsp065/lib/dynlib_<your-ID>.git
- 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
- Then you have to push your new version to a repository that other people can read.
git push own