Hi all, The move to GitHub is now complete. Yay!
https://github.com/atmtools/arts/ In this mail I'll summarise the most important changes in the development workflow. 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: https://github.com/atmtools/arts/blob/master/CONTRIBUTING.md 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 Subversion). - 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 branches. 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, Oliver _______________________________________________ arts_dev.mi mailing list arts_dev.mi@lists.uni-hamburg.de https://mailman.rrz.uni-hamburg.de/mailman/listinfo/arts_dev.mi
