Querying Versioned Software Repositories

Software developers have used version control systems for years, to manage source code changes and to enable them to reproduce any given level of their software from the source code that created it. Most writing departments, however, tend to perform full-scale weekly backups at best or tempt fate by not performing any backups at worst. The two major reasons for this neglect of document version control are lack of adequate tools and the effort required by writers to deal with the inadequate tools presently available. This paper describes a tool I developed at IBM, the Automated Backup Manager (ABM), which attempts to connect the writer's documentation to a true source version control system, without reducing writer productivity.

In the era of Big Code, when researchers seek to study an increasingly large number of repositories to support their findings, the data processing stage may require manipulating millions and more of records. In this work we focus on studies involving fine-grained AST level source code changes. We present how we extended the CodeDistillery source code mining framework with data manipulation capabilities, aimed to alleviate the processing of large datasets of fine grained source code changes. The capabilities we have introduced allow researchers to highly automate their repository mining process and streamline the data acquisition and processing phases. These capabilities have been successfully used to conduct a number of studies, in the course of which dozens of millions of fine-grained source code changes have been processed.

- Version Control is a system that keeps track of the historical changes and usage of a resource within an integrated storage media. Version Control (also widely known as a Source Code Management System) is a crucial component for any team working on software development. Version control will keep a record of every single source code change to a file or document, such as historical data, comparisons between different versions, and even access rights to that file or document. A wise choice on which Version Control system to use will have a massive effect on the performance of the Software Developers. Hence many factors must be acknowledged in the process of making the decision of which product to use. The objective of this research is to find which features/attributes of a Version Control System are most influential in the aforementioned decision making process. The research explores the features/attributes inherent in three well known Version Control systems – Subversion, Mercurial and Git. This is done using ISO 9126 as a criteria. Influential factors in the decision making process are gauged using a descriptive analysis technique, and the instrument used in this case is the Analytical Hierarchy Process (AHP). Extensive questionnaire data was 'fed' into the AHP technique, and based on the results obtained, it was calculated that Subversion is the more favorable Version Control system compared to Mercurial and Git. It can thus be concluded that Subversion is the best Version Control system to support the productivity of software developers. Keywords: Version Control, Subversion, Mercurial, Git, Analytical Hierarchy Process.

Regression test prioritization (RTP) is an active research field, aiming at re‐ordering the tests in a test suite to maximize the rate at which faults are detected. A number of RTP strategies have been proposed, leveraging different factors to reorder tests. Some techniques include an analysis of changed source code, to assign higher priority to tests stressing modified parts of the codebase. Still, most of these change‐based solutions focus on simple text‐level comparisons among versions. We believe that measuring source code changes in a more refined way, capable of discriminating between mere textual changes (e.g., renaming of a local variable) and more structural changes (e.g., changes in the control flow), could lead to significant benefits in RTP, under the assumption that major structural changes are also more likely to introduce faults. To this end, we propose two novel RTP techniques that leverage tree kernels (TK), a class of similarity functions largely used in Natural Language Processing on tree‐structured data. In particular, we apply TKs to abstract syntax trees of source code, to more precisely quantify the extent of structural changes in the source code, and prioritize tests accordingly. We assessed the effectiveness of the proposals by conducting an empirical study on five real‐world Java projects, also used in a number of RTP‐related papers. We automatically generated, for each considered pair of software versions (i.e., old version, new version) in the evolution of the involved projects, 100 variations with artificially injected faults, leading to over 5k different software evolution scenarios overall. We compared the proposed prioritization approaches against well‐known prioritization techniques, evaluating both their effectiveness and their execution times. Our findings show that leveraging more refined code change analysis techniques to quantify the extent of changes in source code can lead to relevant improvements in prioritization effectiveness, while typically introducing negligible overheads due to their execution.

Commit messages, which summarize the source code changes in natural language, are essential for program comprehension and software evolution understanding. Unfortunately, due to the lack of direct motivation, commit messages are sometimes neglected by developers, making it necessary to automatically generate such messages. State-of-the-art adopts learning based approaches such as neural machine translation models for the commit message generation problem. However, they tend to ignore the code structure information and suffer from the out-of-vocabulary issue. In this paper, we propose CoDiSum to address the above two limitations. In particular, we first extract both code structure and code semantics from the source code changes, and then jointly model these two sources of information so as to better learn the representations of the code changes. Moreover, we augment the model with copying mechanism to further mitigate the out-of-vocabulary issue. Experimental evaluations on real data demonstrate that the proposed approach significantly outperforms the state-of-the-art in terms of accurately generating the commit messages.

To collect software bugs found by users, development teams often set up bug trackers using systems such as Bugzilla. Developers would then fix some of the bugs and commit corresponding code changes into version control systems such as svn or git. Unfortunately, the links between bug reports and code changes are missing for many software projects as the bug tracking and version control systems are often maintained separately. Yet, linking bug reports to fix commits is important as it could shed light into the nature of bug fixing processes and expose patterns in software management. Bug linking solutions, such as ReLink, have been proposed. The demonstration of their effectiveness however faces a number of issues, including a reliability issue with their ground truth datasets as well as the extent of their measurements. We propose in this study a benchmark for evaluating bug linking solutions. This benchmark includes a dataset of about 12,000 bug links from 10 programs. These true links between bug reports and their fixes have been provided during bug fixing processes. We designed a number of research questions, to assess both quantitatively and qualitatively the effectiveness of a bug linking tool. Finally, we apply this benchmark on ReLink to report the strengths and limitations of this bug linking tool.

Augmenting commit classification by using fine-grained source code changes and a pre-trained deep neural language model

The paper proposes a method of parsing for relational algebra expressions, which is based on the use of reverse Polish notation (postfix notation). The operation algorithm of the shunting yard, adapted for processing of operators RA, is presented. The tools of lexical analysis and the mechanism of building a syntax analyser for the language of relational algebra are presented. The algorithm of the software solution in Python is described, which allows convert the operator of relational algebra into SQL queries. Underpin of the data source for the implementation of relational algebra operators the relational database - SQLite.

Fine-grained code change (FGCC) recording tools provide detailed insights into code evolution beyond what traditional version control systems offer, supporting the extensive data collection required for training modern machine learning models. This systematic review analyzed 92 primary studies and found that most FGCC tools were designed to support research on code evolution, developer collaboration, or education and are typically implemented as IDE plugins or client-server applications. Key challenges identified include limited interoperability, sustainability issues due to tight coupling with specific technologies, and privacy concerns. The review recommends developing standardized communication protocols and data schemas to improve FGCC tool integration and facilitate large-scale data collection for AI applications.

Identifying repetitive code changes benefits developers, tool builders, and researchers. Tool builders can automate the popular code changes, thus improving the productivity of developers. Researchers can better understand the practice of code evolution, advancing existing code assistance tools and benefiting developers even further. Unfortunately, existing research either predominantly uses coarse-grained Version Control System (VCS) snapshots as the primary source of code evolution data or considers only a small subset of program transformations of a single kind - refactorings.

The retrieval problem is one of the main reasoning problems for ontology based systems. The retrieval problem for concept C consists in finding all individuals a which satisfy C(a). We present ontology transformation which can help to improve evaluating queries over (sublanguage of) OWL ontologies. Our solution is based on translating retrieval concepts into relational algebra expressions and consequently to SQL queries over a database constructed from the original ontology. Ontology transformation into database is ontology-dependent but fully automatic and it is provided by system TORQue.

Source code comments are a valuable instrument to preserve design decisions and to communicate the intent of the code to programmers and maintainers. Nevertheless, commenting source code and keeping comments up-to-date is often neglected for reasons of time or programmers obliviousness. In this paper, we investigate the question whether developers comment their code and to what extent they add comments or adapt them when they evolve the code. We present an approach to associate comments with source code entities to track their co-evolution over multiple versions. A set of heuristics are used to decide whether a comment is associated with its preceding or its succeeding source code entity. We analyzed the co-evolution of code and comments in eight different open source and closed source software systems. We found with statistical significance that (1) the relative amount of comments and source code grows at about the same rate; (2) the type of a source code entity, such as a method declaration or an if-statement, has a significant influence on whether or not it gets commented; (3) in six out of the eight systems, code and comments co-evolve in 90% of the cases; and (4) surprisingly, API changes and comments do not co-evolve but they are re-documented in a later revision. As a result, our approach enables a quantitative assessment of the commenting process in a software system. We can, therefore, leverage the results to provide feedback during development to increase the awareness of when to add comments or when to adapt comments because of source code changes.

In recent years, researchers have intensively investigated various topics in test prioritization, which aims to re-order tests to increase the rate of fault detection during regression testing. While the main research focus in test prioritization is on proposing novel prioritization techniques and evaluating on more and larger subject systems, little effort has been put on investigating the threats to validity in existing work on test prioritization. One main threat to validity is that existing work mainly evaluates prioritization techniques based on simple artificial changes on the source code and tests. For example, the changes in the source code usually include only seeded program faults, whereas the test suite is usually not augmented at all. On the contrary, in real-world software development, software systems usually undergo various changes on the source code and test suite augmentation. Therefore, it is not clear whether the conclusions drawn by existing work in test prioritization from the artificial changes are still valid for real-world software evolution. In this paper, we present the first empirical study to investigate this important threat to validity in test prioritization. We reimplemented 24 variant techniques of both the traditional and time-aware test prioritization, and investigated the impacts of software evolution on those techniques based on the version history of 8 real-world Java programs from GitHub. The results show that for both traditional and time-aware test prioritization, test suite augmentation significantly hampers their effectiveness, whereas source code changes alone do not influence their effectiveness much.

The constant add up of new features and bug fixes often make invariable changes and refinements inevitable in the software development at regular intervals. The software should enable the end-user to decipher the critical version information about the minutest detail in every software artifact and if it does not, no software can be called as complete or nor is it user-friendly. When developers check in the software files they have to put in the version field manually as a part of header information inside the file. It would be difficult to identify vulnerabilities in the software when the files lack embedded version information which makes it harder for the end users to accurately identify the running version of the software. How can version control system (VCS) help in optimizing the bug traceability time and bug fixing potential? Version control system (VCS) is a software application that helps in collaborative software development of software projects. In order to support this instance, we should analyze which version control system is to be considered and whether to use central repository version control system or local repository version control system. Various functional, non functional evaluation criteria and fundamental requirements like installation, configuration, learning curve, performance, commits, branching, merging, and tagging have been considered for a through comparison of many version control systems. In this paper, we review and analyze the currently used VCS that involved in a view of a collaborative software development for software evolution. And an attempt has also been made to identify the version information in every deliverable file or retain it with the source. We demonstrate and perform survey on current versioning systems like Concurrent Version Control System (CVS), Subversion (SVN), Team Foundation Server (TFS), Git, ACME, Visual Source Safe(VSS), Mercurial and Clear Case, etc. that offers opportunities to test produced results and validate.

Regression tests ensure that existing functionality is not impaired by changes to an existing software system. However, executing complete test suites often takes much time. Therefore, a subset of tests has to be found that is sufficient to validate whether the system under test is still valid after it has been changed. This test case selection is especially important if regression tests are executed manually, since manual execution is time intensive and costly. To select manual test cases, many regression testing techniques exist that aim on achieving coverage of changed or even new code. Many of these techniques base on coverage data from prior test runs or logical properties such as annotated pre and post conditions in the source code. However, coverage information becomes outdated if a system is changed extensively. Also annotated logical properties are often not available in industrial software systems. We present an approach for test selection that is based on static analyses of the test suite and the system's source code. We combine trace link recovery using latent semantic indexing with the metric change coverage, which assesses the coverage of source code changes. The proposed approach works automatically without the need to execute tests beforehand or annotate source code. Furthermore, we present a first evaluation of the approach.