Hi all,

The move to GitHub is now complete. Yay! 


In this mail I'll summarise the most important changes in the development 

1 - Better tracking of changes

With Subversion, being a centralised version control system, every commit had 
to be done right on the server. In the past, this often led to the point where 
larger changes resulted in huge commits that touched many files. A finer 
granularity in commits makes it easier for other developers to follow what's 
going on. It can also help to better track down problems to a specific change 
causing them.

Git is decentralised. You develop in your own fork ("copy") of the repository. 
You can commit your changes more often and thus keep better track of your 
changes before they end up in the "live" version. After merging these 
finer-grained commits will be retained in the main repository, making it easier 
for other developers to follow your changes. If you're working on different 
things simultaneously, branches enable you to keep these things physically 
separate, giving you the opportunity to commit them when they're ready.

Information on how to work with git can be found in this document:


2 - Code Review

Another common practice we'd like to adapt is code review. Having another pair 
of eyes look at the code increases the chance of spotting potential problems as 
early as possible. In GitHub this is done via pull requests. Once you're done 
with your current work, instead of merging your changes directly into the main 
repository, you open a pull request. A maintainer (currently Simon and I), will 
have a look at your changes, request changes if any problems are spotted and 
then merge your branch into the main repository.

3 - No more ChangeLog _file_

The ChangeLog file has been removed for several reasons:

- It is duplicating the information available via the log history of the 
version control system (either 'svn log' or 'git log'). 
- It can lie or not tell the whole truth. If you want to see which files 
changed in a particular commit, looking at the ChangeLog file might only give 
you part of that information. The committer could have forgotten to list _all_ 
the changed files. The version control system know exactly which files have 
changed 'git log --stat'.
- It creates a singular point of merge conflicts when working with branches.

4 - But... what about the ARTS version number?

- It now lives in its own file 'VERSION' in the top level ARTS directory.
- The way we used it also duplicated functionality already provided by the 
version control system (the commit hash in git, or the revision id in 
- The version will only be incremented by the maintainers in the master 
repository. Either when new major new features have been added, the user 
interfaces changed (e.g. changed WSM interfaces). But never in developer 

5 - Code format, not git related but I'll mention it here anyway

Over the years, coding style has "evolved" into very different styles for 
different files in ARTS. After looking at different widely used styles, Simon 
and I decided to go with the Google Coding Style. With clang-format being 
available as a great tool for automatically applying a style to the code (not 
only indentation, but also consistent in-code whitespace), this is a great 
opportunity to bring back consistent formatting to ARTS. I'll send out a 
separate mail with more information on plans how to apply the new format to all 
ARTS code.

I think that's all for now. As with every switch to a new system, I expect 
there to be some rough edges that we have to work out.

Questions or comments are always welcome.

Best wishes and have a great weekend,

arts_dev.mi mailing list

Reply via email to