ITC/USA 2007 Conference Proceedings / The Forty-Third Annual International Telemetering Conference and Technical Exhibition / October 22-25, 2007 / Riviera Hotel & Convention Center, Las Vegas, Nevada / Telemetry missions spanning multiple years of tests often require access to archived configuration data for replay and analysis purposes. The needs for versioning vary from simple file-naming conventions to advanced global database versioning based on the scale and complexity of the mission. This paper focuses on a flexible approach to allow access to current and past versions of multiple test article configurations. Specifically, this paper discusses the characteristics of a versioning system for user-friendly and feature-rich solutions. It analyzes the tradeoffs of various versioning options to meet the needs of a given mission and provides a simple framework for users to identify their versioning requirements and implementation.

This thesis has developed a database solution for storage of interface data which are to different systems in a train, the interface data is used in the design of data communication between different systems in the vehicles. The database solution has focused on following problems: revision control of project related data, consistency of interface data between documentation and database, the possibility to roll back the database to an earlier revision, and the possibility to extract delta documents between two revisions in the database. For demonstration of the database solution, a user interface program has been created which communicates with the database. Revision control of the database has been solved by dividing the project related data into three sections: one approved, one modified, and one revised section. The approved section always contains the latest approved data and thereby the ability to read data even though it is subject for a revision at the moment. The modified section contains data that are currently being changed.  Obsolete data are stored in the revised section. To aviod inconsistency of interface data which are stored in both Word documents and in the database, the data is extracted from the database and inserted into tables in the Word documents. The Word documents contain bookmarks where the tables shall be inserted. Algorithms for rolling back the database to an earlier revision, and to extract delta documents were created. These algorithms are not implemented in the user interface program. As a result from this thesis, the interface data is revision controlled and no data is removed from the database during the change process; the data is moved between sections with different flags and revision numbers. Only if the database is rolled back to an earlier revision, data is removed. The functionality to transfer data from the database into tables in Word documents is verified. / Detta examensarbete har tagit fram en databaslösning för lagring av gränssnittsdata för olika systemenheter i ett tåg, gränssnittsdatat används i konstruktionen av kommunikation mellan olika system i fordonen. Databaslösningen har fokuserats på följande problem: revisionskontroll av projekt relaterat data, att gränssnittsdata överensstämmer mellan dokument och databasen, möjligheten att kunna gå tillbaks till en tidigare revision i databasen, samt möjligheten att kunna exportera delta dokument mellan två revisioner i databasen. För att demonstrera databaslösningen har ett användarprogram skapats som kommunicerar med databasen. Revisionskontroll i databasen har lösts genom att dela upp det projektrelaterade datat i tre sektioner: en godkänd, en modifierad samt en reviderad sektion. I den godkända sektionen finns alltid det senast godkända datat och möjligheten att läsa dessa data även om den är under ändring. I den modifierade sektonen finns data som är under pågående ändring. Data som har blivit ersatt återfinns i den reviderade sektionen. För att undvika inkonsekvens av gränssnittssdata som återfinns både i Word-dokument samt i databasen, extraheras datat från databasen till tabeller i Word-dokumenten. Word-dokumenten innehåller bokmärken där tabellerna sätts in. Algoritmer är framtagna för att kunna backa tillbaka till en tidigare revision i databasen samt kunna exportera delta dokument. Dessa algoritmer är inte implementerade i användarprogrammet. Detta examensarbete har resluterat i att gränssnittsdatat är revisionskontrollerat och inget data tas bort från databasen under en ändringsrutin, datat flyttas bara mellan olika sektioner med olika flaggor och revisionsnummer. Endast om man går tillbaks till en tidigare revision tas data bort ur databasen. Funktionaliteten att överföra gränssnittsdata från databasen till tabeller i Word-dokument är verifierad.

One of the main reasons why developers investigate code history is to search for the rationale for code commits. Existing work found that developers report that rationale is one of the most important aspects to understand code changes and that it can be quite difficult to find. While this finding strongly points out the fact that understanding the rationale for code commits is a serious problem for software engineers, no current research efforts have pursued understanding in detail what specifically developers are searching for when they search for rationale. In other words, while the rationale for code commits is informally defined as, "Why was this code implemented this way?" this question could refer to aspects of the code as disparate as, "Why was it necessary to implement this code?"; "Why is this the way in which it was implemented?"; or "Why was the code implemented at that moment?" Our goal with this study is to improve our understanding of what software developers mean when they talk about the rationale for code commits, i.e., how they "unfold" rationale. We additionally study which components of rationale developers find important, which ones they normally need to find, which ones they consider specifically difficult to find, and which ones they normally record in their own code commits. This new, detailed understanding of the components of the rationale for code commits may serve as inspiration for novel techniques to support developers in seeking and accurately recording rationale. / MS / Modern software systems evolution is based on the contribution of a large number of developers. In version control systems, developers introduce packaged changes called code commits for various reasons. In this process of modifying the code, the software developers make some decisions. These decisions need to be understood by other software developers. The question “why the code is this way?” is used by software developers to ask for the rationale behind code changes. The question could refer to aspects of the code as disparate as, “Why was it necessary to implement this code?”; “Why is this the way in which it was implemented?”; or “Why was the code implemented at that moment?” Our goal with this study is to improve our understanding of what software developers mean when they talk about the rationale for code commits, i.e., how they “unfold” rationale. We additionally study which components of rationale developers nd important, which ones they normally need to nd, which ones they consider specically dicult to nd, and which ones they normally record in their own code commits. This new, detailed understanding of the components of the rationale for code commits will allow researchers and tools builders to understand what the developers mean when they mention rationale. Therefore, assisting the development of tools and techniques to support the developers when seeking and recording rationale.

Today a lot of software projects are using version control systems for maintaining their software source code. There are a lot of version control systems, and the choice of which one to choose is far from simple. Today the two biggest version control systems are Git and Subversion. In this paper we have found the main differences between the two, and investigated how the choice between them affects software developers. Although software developers in many aspects are unaffected by the choice, we did find some interesting findings. When using Git, our empirical study shows that software developers seem to check in their code to the main repository more frequently than they do when using Subversion. We also found indications that software developers tend to use Subversion with a graphical interface, whereas the preferred interface for working with Git seems to be command-line. We were also surprised of how insignificant the learning aspect of the systems seems to be for the developers. Our goal with this paper is to provide a foundation to stand upon when choosing what version control system to use for a software project.

Software development is driven by the development team's decisions. Communicating the rationale behind these decisions is essential for the projects success. Although the software engineering community recognizes the need and importance of rationale, there has been a lack of in-depth study of rationale for code changes. To bridge this gap, this dissertation examines the rationale behind code changes in-depth and breadth. This work includes two studies and an experiment. The first study aims to understand software developers' need. It finds that software developers need to investigate code changes to understand their rationale when working on diverse tasks. The study also reveals that software developers decompose the rationale of code commits into 15 separate components that they could seek when searching for rationale. The second study surveys software developers' experiences with rationale. It uncovers issues and challenges that software developers encounter while searching for and recording rationale for code changes. The study highlights rationale components that are needed and hard to find. Additionally, it discusses factors leading software developers to give up their search for the rationale of code changes. Finally, the experiment predicts the documentation of rationale components in pull request templates. Multiple statistical models are built to predict if rationale components' headers will not be filled. The trained models are effective in achieving high accuracy and recall. Overall, this work's findings shed light on the need for rationale and offer deep insights for fulfilling this important information need. / Doctor of Philosophy / Software developers build software by creating and changing the software's code. In this process, developers make decisions and other developers need to understand these decisions. The rationale behind code changes is an important piece of information that leads to development success if well explained and understood. In this work, we study the developers' need for rationale by conducting two studies and an experiment. In the first study, we found that software developers often need to look into the rationale behind code changes to understand them better while working on different tasks. We identified 15 different parts of rationale that developers seek when searching for rationale for code changes. The second study focused on the experiences of software developers when looking for and recording rationale. We discovered some challenges that developers face, like difficulty in finding specific rationale parts and the factors that make developers give up searching for rationale. The experiment predicts if developers would document rationale in specific templates. We built models to predict if certain parts of rationale would be left empty, and the models were effective. Overall, this research provides a better understanding of software developers' need, and it provides valuable insights to help fulfill this important information need.

Stärker verteilte Systeme in der Planung und Produktion verbessern die Agilität und Wartbarkeit von Einzelkomponenten, wobei gleichzeitig jedoch deren Vernetzung untereinander steigt. Das stellt wiederum neue Anforderungen an die semantische Beschreibung der Komponenten und deren Verbindungen, wofür Informations- und Datenmodelle unabdingbar sind. Der Lebenszyklus dieser Modelle ist dabei von Änderungen geprägt, mit denen umgegangen werden muss. Heutige Revisionsverwaltungssysteme, die die industriell geforderte Nachvollziehbarkeit bereitstellen könnten, sind allerdings nicht auf die speziellen Anforderungen der Informations- und Datenmodelle zugeschnitten, wodurch Möglichkeiten einer konsistenten Evolution verringert werden. Im Rahmen dieser Dissertation wurde ein Revision Management System zur durchgängigen Unterstützung der Evolution von Informations- und Datenmodellen entwickelt, das Revisionsverwaltungs- und Evolutionsmechanismen integriert. Besonderheit ist hierbei die technologieunabhängige mathematische und semantische Beschreibung, die eine Überführung des Konzepts in unterschiedliche Technologien ermöglicht. Beispielhaft wurde das Konzept für das Semantic Web als Weiterentwicklung des Open-Source-Projektes R43ples umgesetzt. / The increased distribution of systems in planning and production leads to improved agility and maintainability of individual components, whereas concurrently their cross-linking increases. This causes new requirements for the semantic description of components and links for which information and data models are indispensable. The life cycle of those models is characterized by changes that must be dealt with. However, today’s revision control systems would provide the required industrial traceability but are not enough for the specific requirements of information and data models. As a result, possibilities for a consistent evolution are reduced. Within this thesis a revision management system was developed, integrating revision control and evolution mechanisms to support the evolution of information and data models. The key is the technology-independent mathematical and sematic description allowing the application of the concept within different technologies. Exemplarily the concept was implemented for the Semantic Web as an extension of the open source project R43ples.

The goal of this work is to design a generally useful versioning system for the administration of different types of electronics documents, to design in detail and to implement the client part of this system (based on the client-server model). The implementation is built on .NET platform. This text also describes general approaches to versioning in different systems and shows a survey over the principles of the existing versioning systems with respect to the interaction with user.