When performing an analysis of the evolution of software quality and software metrics,there is a need to get access to as many versions of the source code as possible. There isa lack of research on how data or source code can be extracted from the source controlmanagement system Git. This thesis explores different possibilities to resolve thisproblem. Lately, there has been a boom in usage of the version control system Git. Githubalone hosts about 6,100,000 projects. Some well known projects and organizations thatuse Git are Linux, WordPress, and Facebook. Even with these figures and clients, thereare very few tools able to perform data extraction from Git repositories. A pre-studyshowed that there is a lack of standardization on how to share mining results, and themethods used to obtain them. There are several tools available for older version control systems, such as concurrentversions system (CVS), but few for Git. The examined repository mining applicationsfor Git are either poorly documented; or were built to be very purpose-specific to theproject for which they were designed. This thesis compiles a list of general issues encountered when using repositorymining as a tool for data gathering. A selection of existing repository mining tools wereevaluated towards a set of prerequisite criteria. The end result of this evaluation is thecreation of a new repository mining tool called Doris. This tool also includes a smallcode metrics analysis library to show how it can be extended.

Cette thèse, articulée en deux parties, présente le calcul des corrections radiatives à la diffusion Compton virtuelle (VCS) et décrit la méthode magnétique (projet ARC) adoptée dans le Hall A à Jefferson Lab. pour mesurer l'énergie absolue du faisceau d'électrons avec une précision de 10-4.<br /><br />Les expériences de diffusion Compton virtuelle nous permettent d'accéder à de nouvelles observables du proton : les polarisabilités généralisées. L'extraction de ces polarisabilités s'effectuant par comparaison des sections efficaces expérimentale et théorique, il est indispensable de contrôler avec une grande précision les erreurs systématiques et les effets radiatifs liés à l'expérience. Un calcul complet des corrections radiatives internes a donc été mené dans le cadre de l'électrodynamique quantique. Ce calcul inédit tient compte de tous les graphes contribuant à l'ordre alpha^4 au niveau de la section efficace à l'exception de ceux mettant en jeu l'échange de deux photons entre les bras leptonique et hadronique ainsi que ceux relatifs au rayonnement du proton. La méthode de régularisation dimensionnelle a été employée pour le traitement des divergences ultraviolettes et infrarouges. Après utilisation d'une procédure d'addition-soustraction, la compensation infrarouge est vérifiée. Nous avons privilégié le calcul analytique pour les intégrales les plus internes et avons eu ensuite recours à un traitement numérique spécifique. Les résultats présentés correspondent aux différentes cinématiques de l'expérience VCS qui s'est déroulée à TJNAF en 1998. <br /><br />La méthode de mesure absolue d'énergie que nous avons développée s'appuie sur la déviation magnétique, constituée de huit dipôles identiques, conduisant le faisceau de l'accélérateur au hall A expérimental. L'énergie est déterminée à partir de la mesure absolue de l'angle de déviation du faisceau dans le plan horizontal et de la mesure absolue de l'intégrale de champ magnétique le long de la déviation magnétique. La mesure de l'angle de déviation se décompose en une mesure ponctuelle d'un angle de référence (par une méthode optique d'autocollimation) et en une mesure « en ligne » des déviations angulaires du faisceau par rapport à cet angle de référence (utilisation de quatre profileurs à fil : une paire en amont et une paire en aval de l'arc). L'intégrale de champ absolue le long de la déviation résulte, elle, de la mesure ponctuelle de la somme des intégrales de champ relatives des huit dipôles de l'arc par rapport à un aimant de référence et de la mesure « en ligne » de l'intégrale de champ de cet aimant de référence alimenté en série avec les huit autres de l'arc.

No description available.

No description available.

När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. “integration hell” där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas.En strategi som man kan ta till är “continuous integration”, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. “CI-system” som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden “continuous integration”.Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som “funktionella” och “icke-funktionella” krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran “TeamCity”.Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel. / When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called “integration hell” where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called “continuous integration”. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a “way to do things” rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system.This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into “functional requirements” and “non-functional requirements (quality attributes)”. By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software ”TeamCity”. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues.