FEATURES OF TRAINING OF FUTURE INFORMATICS TEACHERS WORKING WITH THE GIT VERSION CONTROL SYSTEM GIT

Teamwork is the most important soft skill of the modern specialist, not to mention a teacher. It is also undisputed that skills development is very important to start at school, in particular at computer science lessons. Accordingly, a future teacher of computer science has to know version control systems and use one of them to organize collective student's work like in class and in the process of preparing for science competitions of the Junior Academy of Sciences of Ukraine. This topic of the article is relevant because it doesn't fully describe in the scientific and methodological resources. The main goal of this article is to open the main features of teaching students to work with version control systems on the example of Git. The systematic approach was the methodological basis for the investigation discovery. But besides, the researcher analyzed, compared, and summarized the investigation and experience of the leading scientists. As the result of the article the author rise to the following conclusions that the knowledge of version control systems (in particular Git) is an important part of the preparation of computer science teachers; teaching students to work with such programs have to be combined with the study of programming; should be encouraged students to complete labs and case studies using Git; teachers have to demonstrate through examples the correct organization and culture of work with such programs. The writer is also considering using the GitHub Classroom service to organize the educational process subjects such as programming and page making of web pages.

Maintaining private views in Java

<p>When developers collaborate on a project there are times when the code diverges. When this happens the code may need to be refactored to best suit the changes before they are applied. In these situations it would be valuable to have a private view. This view would be functionally equivalent to other views and be able to present the code in a different form. It enables a developer to refactor or change the code to their tastes, with minimal impact on other developers. Changes in the order of methods and the addition of comments currently impact other developers even if there is no change in how the code works. The Refactor Categories Tool has been written to detect where Java source code has been moved within a file or comments have been added, removed or edited. This indicates that it would be useful for version control systems to differentiate between changes to a program that also change the behaviour and those that do not.</p>

Maintaining private views in Java

<p>When developers collaborate on a project there are times when the code diverges. When this happens the code may need to be refactored to best suit the changes before they are applied. In these situations it would be valuable to have a private view. This view would be functionally equivalent to other views and be able to present the code in a different form. It enables a developer to refactor or change the code to their tastes, with minimal impact on other developers. Changes in the order of methods and the addition of comments currently impact other developers even if there is no change in how the code works. The Refactor Categories Tool has been written to detect where Java source code has been moved within a file or comments have been added, removed or edited. This indicates that it would be useful for version control systems to differentiate between changes to a program that also change the behaviour and those that do not.</p>

Tools for organizing teachers-students interaction using version control systems

The article describes an approach to organizing the teacher-students interaction in programming courses using the Git version control system. In order to select the most suitable and affordable system for educational needs a comparative analysis of different Git repository management systems was carried out. Based on the experience of various educational institutions that use version control systems in their courses, the advantages and disadvantages of using these systems in teaching were identified. Taking into account the existing problems, a software solution was developed based on the GitLab system. As part of this solution, a method is proposed for organizing the work of a teacher and students in disciplines that use version control systems. This approach implies using both GitLab and additional system, which serves as a manager for Git repositories and is designed to facilitate the work of the teacher and administrator by automating the tasks they perform. The main purpose of the article is a detailed description of this approach: limiting permissions to both teachers and students, GitLab organization and functionality, a list of use cases for each user. The article also presents common workflows of the additional system, its main entities and their relationships and an overview of the features that the system provides.

A Rapid Transition from Subversion to Git: Time, Space, Branching, Merging, Offline commits & Offline builds and Repository aspects

Background: Software development is being transitioned from centralized to decentralized version control systems. This transition is driven by the limited features of centralized version control systems in terms of branching, merging, time, space, offline commits & builds, and repository aspects. Transition from Subversion, a centralized version control system, to Git, a decentralized version control system, has been focused in a limited way. Objective: In this work, the transition process from Subversion Version Control System (VCS) to Git VCS has been investigated in terms of time, space, branching, merging, and repository aspects from the software developer point of view working individually or in a large team over a large and complex software having a legacy of many decades. Experimentation was conducted in SRLC Software Research Lab, Chicago, USA. Methods: Various scripts have been developed and executed for version control using Git and performed over a few legacy software. Results: The results show that branching in Git and Subversion has a difference of about 39 times, i.e., branching operation of Git is about 39 times faster than Subversion. Merging in the case of Git is trivial and automatic, while Subversion needs a manual process of merging, which is error-prone. Using an example of Mozilla with FSFS backend, it is observed that disk space can be saved up to 30 times in Git compared to Subversion. By taking a typical example of a large-sized project, it is observed that Git requires almost half of the revisions compared to Subversion; furthermore, with FSFS backend, a project having ten years of history with 240,000 commits needs 240 directories in case of Subversion, while Git requires only 2 directories. Using offline commits and offline builds of Git, it is observed that in Git, whitespace changes, in contrast to significant business logic changes, can be staged in one commit only. These are not possible in Subversion, which requires a complicated system of diffing to temporary files. It is also observed that Git provides an offline commit facility, i.e., in case if, for some reason, the remote repository is unavailable due to disaster or network failure, then developers can still offline commit their code and execute the offline build. Conclusion: However, no previous study was found that focused on how the choice actually affects software developers and this formed the motivation for the present work. In this work, a list of how the choice between Git and Subversion affects software developers is worked out. Although software developers in many aspects are unaffected by the choice, few interesting findings were achieved. One of the most interesting findings of the proposed work is that software developers seem to publish their code to the main repository more often in Git than in Subversion. It is also found that the majority of the software developers perform at least two commits per push, which means that Git repositories will contain a lot more saved points in history than Subversion repositories.

variED: an editor for collaborative, real-time feature modeling

Feature models are a helpful means to document, manage, maintain, and configure the variability of a software system, and thus are a core artifact in software product-line engineering. Due to the various purposes of feature models, they can be a cross-cutting concern in an organization, integrating technical and business aspects. For this reason, various stakeholders (e.g., developers and consultants) may get involved into modeling the features of a software product line. Currently, collaboration in such a scenario can only be done with face-to-face meetings or by combining single-user feature-model editors with additional communication and version-control systems. While face-to-face meetings are often costly and impractical, using version-control systems can cause merge conflicts and inconsistency within a model, due to the different intentions of the involved stakeholders. Advanced tools that solve these problems by enabling collaborative, real-time feature modeling, analogous to Google Docs or Overleaf for text editing, are missing. In this article, we build on a previous paper and describe (1) the extended formal foundations of collaborative, real-time feature modeling, (2) our conflict resolution algorithm in more detail, (3) proofs that our formalization converges and preserves causality as well as user intentions, (4) the implementation of our prototype, and (5) the results of an empirical evaluation to assess the prototype’s usability. Our contributions provide the basis for advancing existing feature-modeling tools and practices to support collaborative feature modeling. The results of our evaluation show that our prototype is considered helpful and valuable by 17 users, also indicating potential for extending our tool and opportunities for new research directions.

Constructing Bug Knowledge Graph as a Service for Bug Search

When encountering bug issues, developers tend to search the bug repository and commit repository for references. However, the links between bug reports and commits in version control systems are often missed, and the information in bug repository and commit repository can provide is simple. When developers search a bug issue, they can only get the information of bug reports or commits, which are loose and difficult for developers to refer. What’s more, many searching results are not accurate. To deal with these problems, this paper proposes an approach to deal with the bug and commit information with the topic model, and construct bug knowledge graph as a service to assist in bug search. In addition, as the amount of bug related information continuously increase, it is time-consuming to update the data. We can automatically update the bug knowledge graph with the LTM topic model (a lifelong topic model). Finally, the experiment with the bug reports from Bugzilla@Mozilla and the corresponding commits from Github was conducted. The experiment results show that our approach is effective and efficient to help developers search relevant bugs for reference by constructing the bug knowledge as a service.