Sidebar
2.4.1 Excursion to the version control system GIT
GIT is a distributed version control system. A major difference between GIT and SVN is that GIT is decentralized. This means that there is no single central server on which the Gambas sources and especially their history are stored in the original. While SVN is centralized, at GIT every developer has the complete version history of Gambas locally on his hard disk. If something had happened to the SVN server in Sourceforge at some point, the complete history of the Gambas source code would be lost. At SVN, everyone has only the current version of the source code - whose history is stored on a single server.
One of the consequences of this is that you can work offline with GIT. With SVN you need an active internet connection to' commit' (' check in'). Yes, you even need an internet connection to display the commit logs from last week, for example, because only the server has one. This is annoying for developers because it takes a long time. GIT does not have this problem, so it is considered the superior system.
A further advantage of GIT from the point of view of the developers are the so-called branches, which represent branches of the version history. In both GIT and SVN it is possible to have a non-linear, tree-like version history. For example, Boege could work on a new component while Minisini corrects errors, screws Bodard on sample projects, Prokopowicz rewrites a component, and Lenngren might try to convert gb. jit to a new version of LLVM over a longer period of time. This results in five branches of development that run parallel and separate from a common point in time in the (gambas) version history. Later, these threads will be merged back to the main branch of Gambas - but only when the task of each branch has been processed and completed.
Tags, on the other hand, are stable versions and therefore tags are not development branches (? head detached) of gambas. A day is not a branch of development from which gambas could develop. A tag is just a window into the history of a version. The further development of v3.10.0 will, for example, one day be v3.10.1. For example, you can list all tags (i. e. all stable versions of gambas):
$ cd path_to_the_gambas_repository $ git tag | sort -V
where the list is displayed sorted. The highest version number - current stable version - appears as the last entry in the list.
The above-mentioned has never before been done like this in Gambas. It's always been the case that all the developers followed their tasks simultaneously and completely side-by-side on the only major branch of version history. The reason for this is that branches in SVN are unbelievably sluggish entities. A branch in SVN is basically a complete copy of the entire repository and that's a lot of files.
The distributed nature of GIT favours independent developments and the branches are also important, and they are implemented in a lean way! Creating a new branch is in the blink of an eye, you can start right away. Once you've finished with the Branch, it will (if nothing went wrong) be added to the main branch of version history in record time. The latter remains very nicely arranged and is not made more unstable than it has to be by semi-finished approaches. Branches are one of GIT's greatest strengths.
Let's get back to decentralization: In GIT, everyone has their own local and independent copy of Gambas on the hard disk. In practice, however, the developers will exchange ideas and share their commits with each other. This refers to the second level indicated above. On the upper level is the GitLab. com website, which will replace SourceForge. net as of August 12,2017. With the relocation of the mailing list to http://lists.gambas-basic.org. on 15 October 2017, the change from SVN to GIT is complete. GitLab is a host for GIT projects. This is where the developers of a project come together and exchange their own software changes with each other. For example, you can also report errors or send the developers source code, which they can then check and include in the project.
In the future, GitLab will be the central contact point for getting the Gambas source packages. This is also true, because the underlying GIT system means that you are immune to some of the dangers of centralisation. Work for developers is also becoming more pleasant in some respects.
Is there still the question of what changes for developers and users when switching from SVN to GIT? Only the access to the source code changes. Everything else, such as the installation of gambas, remains the same. Basically, you only have to replace the two svn commands you used before:
SVN - SourceForge:
# Load the whole repository $ svn checkout svn://svn.code.sf.net/p/gambas/code/gambas/trunk # Get updates $ svn update
GIT - GitLab:
# Load the whole repository $ git clone https://gitlab.com/gambas/gambas # Get updates $ git pull
Further information about GIT can be found on these pages:
http://gambaswiki.org/wiki/howto/git ' Required reading https://gitlab.com/gambas/gambas https://git-scm.com/book/en/v2 https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet https://de.wikipedia.org/wiki/Git https://rogerdudler.github.io/git-guide/ https://www.sbf5.com/~cduan/technical/git/
Page Tools
