Supporting Streams of Changes during Branch Integration

International audienceWhen developing large applications, integrators face the problem of integrating changes between branches or forks. While version control systems provide support for merging changes, this support is mostly text-based, and does not take the program entities into account. Furthermore, there exists no support for assessing which other changes a particular change depends on have to be integrated. Consequently, integrators are left to perform a manual and tedious comparison of the changes within the sequence of their branch and to successfully integrate them. In this paper, we present an approach that analyzes changes within a sequence of changes (stream of changes): such analysis identifies and characterizes dependencies between the changes. The approach identifies changes as autonomous, only used by others, only using other changes, or both. Such a characterization aims at easing the integrator's work. In addition, the approach supports important queries that an integrator otherwise has to perform manually. We applied the approach to a stream of changes representing 5 years of development work on an open- source project and report our experiences

Aide à l'Intégration de Branches Grâce à la Réification des Changements

Developers typically change codebases in parallel from each other, which results in diverging codebases. Such diverging codebases must be integrated when finished. Integrating diverging codebases involves difficult activities. For example, two changes that are correct independently can introduce subtle bugs when integrated together. Integration can be difficult with existing tools, which, instead of dealing with the evolution of the actual program entities being changed, handle code changes as lines of text in files. Tools are important: software development tools have greatly improved from generic text editors to IDEs by providing high-level code manipulation such as automatic refactorings and code completion. This improvement was possible by the reification of program entities. Nevertheless, integration tools did not benefit from a similarreification of change entities to improve productivity in integration.In this work we first conducted a study to learn which integration activities are important and have little tool support. We discovered that one of such activities is the detection of tangled commits (that contain unrelated tasks such as a bug fix and a refactoring). Then we proposed Epicea, a reified change model and associated IDE tools, and EpiceaUntangler, an approach to help developers share untangled commits based on Epicea. The results of our evaluations with real-world studies show the usefulness of our approaches.Les développeurs changent le code source en parallèle les uns des autres, ce qui fait diverger les bases de code. Ces divergences se doivent d'être réintégrées.L'intégration de bases de code divergentes est une activité complexe. Par exemple, réunir deux bases de code indépendamment correctes peut générer des problèmes. L'intégration peut être difficile avec les outils existants, qui, au lieu de gérer l'évolution des entités réelles du programme modifié, gère les changements de code au niveau des lignes de texte dans les fichiers sources.Les outils sont importants: les outils de développement de logiciels se sont grandement améliorés en passant par exemple d'éditeurs de textegénériques à des IDEs qui fournissent de la manipulation de code de haut niveau tels que la refactorisation automatique et la complétion de code. Cette amélioration a été possible grâce à la réification des entités de programme. Néanmoins, les outils d'intégration n'ont pas profité d'une réification similaire des entités de changement pour améliorer l'intégration.Dans cette thèse nous avons d'abord conduit une étude auprès de développeurs pourcomprendre quelles sont les activités menées durant une intégration quisont peu supportées par les outils. L'une d'elle est la détection de commits mêlés (qui contiennent des tâches non liées telles qu'une correction de bug et une refactorisation).Ensuite, nous proposons Epicea, un modèle de changement réifié et des outils d'IDE associés, et EpiceaUntangler, une approche pour aider les développeurs à démêler les commits en se basant sur Epicea.Les résultats de nos évaluations avec des études de cas issues du monde réel montrent l’utilité de nos approches

Ansatz einer entwicklungsprojektweiten Abhängigkeits-Konsistenz des Quellcodemodells zur Qualitätsverbesserung von Software-Entwicklungsprojekten

Heutige Softwareentwicklungsprojekte müssen oft eine Vielzahl von Anforderungen mit hoher Komplexität in kurzen Release-Zyklen umsetzen. Daraus ergeben sich besondere Herausforderungen an Arbeitsteilung, Dokumentation, Prozesssicherheit und Qualität. Entwicklungsarbeiten müssen parallelisiert werden und Softwareentwickler müssen sich immer wieder in den Quellcode einarbeiten. Die Entwickler brauchen schnelle und präzise Rückmeldung über die Qualität ihrer durchgeführten Änderungen am Quellcode. Über feingranulare Traceability Links in den Quellcode werden eine verbesserte Dokumentation und größere Prozesssicherheit ermöglicht. Dazu wird ein Metamodell für den Quellcode definiert und in ein Metamodell mit Anforderungsmanagement, Änderungsmanagement, Testdatenmanagement und Dokumentation eingebunden. Das gesamte Modell wird in einem Software Configuration Management (SCM) Repository abgespeichert, um die Versionierung aller Artefakte und Links zu ermöglichen. In einem Quellcode Editor können die Traceability Links erstellt und genutzt werden. Die Historie einzelner Quellcode Artefakte kann einschließlich der Traceability Links im Editor zur Anzeige gebracht werden. Durch das Vorliegen des Quellcodes als Modell wird auch ein feingranulares pessimistisches Sperren einzelner Modell Artefakte ermöglicht. Damit ist das parallele Bearbeiten einer Klasse oder einer Methode möglich, ohne dass der Quellcode verschmolzen werden muss. Es werden durch die Sperren auch Syntaxfehler im SCM Repository verhindert. Im Quellcode Editor werden die Sperren anderer Entwickler angezeigt. Continuous Integration wird dahingehend erweitert, dass durch Abspeichern von Class-Dateien im Repository ein schneller Produkt-Build und damit auch schnelleres Feedback für den Entwickler ermöglicht wird. Durch Testauswahlstrategien werden nur für den geänderten Quellcode relevante Tests ausgeführt. Eine Testauswahlstrategie verwendet dabei die Traceability Informationen zwischen geänderten Quellcode, Anforderung, Testspezifikation und dem Test-Quellcode. In großen Projekten entstehen auf Grund des Quellcodes sehr große Modelle, die eine Herausforderung bezüglich Speicherbedarfes und Performance darstellen. Es wurden Untersuchungen an Hand eines Projekts mit 6,5 Millionen Quellcode-Zeilen durchgeführt. Für diese Konzepte wurde ein Prototyp auf Basis der Eclipse Entwicklungsumgebung und für Java entwickelt