2 Introduction. 2.1 The purpose of version control. Code management for Smalltalk

Größe: px
Ab Seite anzeigen:

Download "2 Introduction. 2.1 The purpose of version control. Code management for Smalltalk"


1 1 Introduction Traditionally, source code in Squeak is managed though projects and changesets. Although this works moderately well for single-person development, it is cumbersome and unreliable for concurrent development within even a small team: there is no easy way to merge concurrent changes or to resolve conflicts between them, method versions are only tracked in each developer s local image, and keeping multiple images in sync generally involves a chaos of ed changeset files. It also takes discipline and effort when working with multiple related projects to ensure that the changes are all sorted to the proper changeset and that none of them gets lost. Monticello was developed to address this issues and became the state of the art version control system in Squeak. But it has some downsides which were the reasons why SqueakSVN was developed. This issues are addressed in the first chapter which covers the workflow of SqueakSVN compared to the workflows of code management systems in Squeak especially Monticello and other Smalltalk version control systems. The second chapter introduces into the architecture of SqueakSVNs graphical user interface architecture and discusses some implementation details. It provides the knowledge to exchange the user interface of the the applications. Additionally, it delivers an overview of the tools of SqueakSVN. Subversion is used to solve the issues of Monticello by using it as a back-end. Because Subversion can only version files and Squeak is a purely object-oriented language, a mapping was needed to map the objects of Squeak to the file system. This mapping is discussed in detail in chapter three. Squeak allow different ways to integrate external programs and Subversion allows also different way to access its functionality. The fourth chapter covers these topics and discusses the problems and the solution how SqueakSVN interfaces Subversion. In the chapter five current version control systems are analyzed and compared to evaluate and classify version control systems. 1

2 Code management for Smalltalk 2 Introduction Most developers have a high need to control the software development process, especially if they work together in teams. For this purpose SqueakSVN was developed to support Squeak developers with the benefits of the version control system Subversion. The first chapter introduces the reader into SqueakSVN and its corresponding topics from an end user perspective. In this process the reader receives a presentation of the workflow of SqueakSVN compared to the workflows of other Smalltalk code management systems, focusing on the aspects of version control and team development. Furthermore the set of tools which helps developers to integrate SqueakSVN into their workflow and supports them to use SqueakSVNs functionality effectively is discussed. This section provides an introduction into the topic of version control and the basics of SqueakSVN. Subsequently section 3 covers the basic workflow in SqueakSVN. Section 4 deals with the team development features and their integration into the basic workflow. section 5 compares the workflow of SqueakSVN to other code management systems in Squeak and other Smalltalk environments keeping the aspects of version control and team development in mind. Then this comparision is evaluated in section 5.5. In section 6 the usage of the tools of SqueakSVN is debated. Finally the appendix covers other user specific topics. 2.1 The purpose of version control The purpose of version control systems is to help software developers to cooperate and to version their software while it is in the developing process. The main issues are to keep record of all occurring changes, to recognize who made a change, to inform other developers about new changes and to support them with the integration of new changes into their current work. Specifically the version control systems record every change made to a program. As a result developers have a development history, like a backup of every stage of development, in which they can review all changes in the software. If anybody needs to review a previous code or a previous version of a file, the history can be consulted. Coordination is also an important aspect and is considered when it comes to distributing the changes between developers. As a result of the distribution a version control system needs to help them not to interfere in the work of each other. But if it does happen it should also help to solve this conflict. Assuming Adam and Henry are two developers who would like to develop a Pong clone for Squeak by using the features mentioned above in this process. This example is used to illustrate the features and the workflow of SqueakSVN. 2

3 2.2 General concepts of version control It is necessary to explain general concepts of version control to help the reader understand the different code management and version control systems Changesets Changes made to an application can be saved in collections known as changesets. Sometimes these changes are dependent on each other therefore their order is important. If there is a class and it contains a method, the creation of the class and the method are two changes, but a method cannot be created for a class if this class does not exist Packages and Patches Changesets can be saved as patches or as packages. A patch is a changeset, which can be applied on current codes. A project can consist of many patches which are applied next to each other on the code base and a patch can be removed to undo certain changes to this code. On the contrary packages contain only the code which is the result of applying changes to the code base while patches contain only the changes. As a consequence distributing patches is faster than distributing packages because patches are smaller Repository Repositories are places where participating developers can store and share their changesets. They are categorized into central repositories and distributed repositories. In Subversion and SqueakSVN a changeset send to the repository is called a revision. Keeping this in mind a revision contains all changes made from the previous revision to the new one. Also the latest revision is called the head revision. Adam and Henry need for their Pong clone a central repository to work with SqueakSVN. The creation of Subversion repositories for SqueakSVN is covered in section Working copy If Adam and Henry have access to a repository they need to create a local mirror of the file structure in the repository at a particular revision, called the working copy. Then they work on the working copy and do not modify the repository. A working copy is created automatically when a project for SqueakSVN is created. The next section explains also what SqueakSVN projects are. 2.3 Organization of SqueakSVN Squeak runs in a virtual machine and everything in Squeak is an object and exists at runtime in the cache. Applications in Squeak are set up of classes and methods which are also objects [1]. Subversion works on files and can not access and version these 3

4 classes and methods. Therefore SqueakSVN needs to write and read these semantic units from and into the working copy. This whole process of writing and reading is known as mapping and is discussed in chapter?? Elements SqueakSVN organizes itself with elements which are the representation of the objects which are versioned and everything concerning version control is applied on them. Depending on the type of the element they may have child elements. The type could be a versioned method, a versioned class or a project. The different functionalities provided by SqueakSVN are accessible through commands. These commands are located in the context menus when their representation is selected. The basic behaviour is that functionality applied to a particular element is also applied to its children and their children. There are some special cases where the representation of the element is split in more than one. All functionalities are applied on these special cases are not executed on parts of the element but on the whole element. They are discussed in section Projects Projects are the main container and organization unit for classes and methods which should be versioned. When Adam and Henry want to start or to continue to develop their application in an image they need to create a project first. For a better organization Adam and Henry split the application in sub-applications like a GUI project and a game engine project. The process of creating projects is discussed in section Extensions Sometimes it is necessary for Adam and Henry to extend the functionality of an existing super class like Object with a method, a so called extension. They do this by adding a method directly to a project by versioning it. A class can only be versioned by one project therefore it is better that they do not version the super class. The super class can then be extended by more than one project. 3 The workflow of SqueakSVN Subversions workflow is organized in a basic working cycle which was adopted for the purposes in Squeak. This cycle is closed and all steps are repeated in a similar way every day of development. It can be modified, stopped and continued. There are some small cases which can occur that extend the steps but these are addressed in the section 4. There are four steps Update, Modify, Review and Commit shown in figure 1 for an overview. 4

5 Figure 1: Basic SqueakSVN working cycle 3.1 Update Assume Adam s and Henry s project evolved already and Adam develops the GUI project by himself while Henry works on the other project. Adam first updates the project. Updating means to receive the head revision of a project or part of a project from the repository. He can start it by selecting a versioned element and then selecting update in the context menu in the "SqueakSVN Project Browser" or the "SqueakSVN System Browser". The usage of this tools is discussed later in section 6. There is another menu entry located near by called "update to revision...". This command can update the element and its children to every revision where it was changed in the history of the project. This is in particularly of importance if Adam or Henry need to get an older version of a particular element. After choosing this menu entry a context menu opens where different revisions are displayed at which the specific element changed. Adam and Henry usually do the update step once a day before they start to work on code to get the latest changes. Updating is only necessary in a special case discussed later in section Modify The next step Adam takes is to modify the working copy. He can change the GUI by adding, removing or modifying elements of the project. He created already a class in another browser called PongBall and extended the class Point with a method #asvector. Now he wants to add both to the GUI project. He can achieve this by using two browsers. In the "SqueakSVN Project Browser" he can select the project and then select "add class to project" or "add method to project" in the context menu to add the class or the extension to the project. A dialog pops up after that and requires him to enter the class or additionally the method of the class in a second dialog. The class and method are accepted if they exist in the image and if they are not already part of another project. 5

6 The "SqueakSVN System Browser" has another behaviour because Adam needs to select the class or the method and add it with the menu entry of the context menu "Add to current project". Then it is added to the current project which is displayed in the upper part of the "SqueakSVN System Browser". When Adam adds the class to the current project it is checked by SqueakSVN if it is not already versioned in another project or if another project has versioned one of the classes methods. If this class is already versioned by another project then Adam needs to remove it from this project first. If one or more methods of the class are already versioned by another project a message box appears asking him to proceed and add the class without the already versioned methods or to cancel the adding. If Adam adds a method to the current project it is checked by SqueakSVN if the method is versioned anywhere and then added as a versioned method to the already versioned class it belongs to or as an extension. Except adding there is the opposite option to remove an element. If Adam adds the class Object to the GUI project and realizes afterwards that he wants to undo the process he can remove it from version control. He can do this by selecting it and then clicking in the context menu on "remove" but then it is still kept in the image. Only if Adam removes it the common way from the image, e.g. in any System Browser, it is also removed from version control. Adam and Henry can develop in SqueakSVN in their favorite browsers. Every time they modify a class or method its changes are saved in the working copy. Only when they want to access the functionality of SqueakSVN they need the "SqueakSVN Project Browser" or the "SqueakSVN System Browser". But usually the functionality of SqueakSVN is used often and therefore the best practice is to use the "SqueakSVN System Browser" for development and the "SqueakSVN Project Browser" for the management of the projects. 3.3 Review The next step is not necessary but it is recommend. Adam could review his changes to notice some changes which are not finished, wrong or made only by him for testing purposes, like debug outputs. If the changes do not satisfy him he should go one step back and modify the project again. Adam can review his changes in many different ways. In the "SqueakSVN System Browser" he can select a versioned method, click on the "view" button and select "diff". When he selected "diff" then the differences made to the method are displayed. When no modification is done to the method the difference is shown between the last updated revision of the method and the head revision of the method. This happens by showing the code of both methods and highlighting the differences. Adam has modified the class Vector which he got by updating the project. Now he wants to get rid of his changes done to this class by reverting it. He can find this option in the selected elements context menu. This command removes all changes made to a element and a element is back in his state at the last updated revision. In Adams case the class will have the same state when he updated the project. Another important part of reviewing is testing. It is recommend that Adam tests all 6

7 new changes before sending them to the repository because if they create bugs and do not work together with the content of the repository they will corrupt the project and propagate bugs to Henry. A version control system can control the code but not the interacting system while it is running. 3.4 Commit When Adam has reviewed his changes and is satisfied with them then he needs to send his changes to the repository. In Subversion this process is called committing and is an atomic operation. A commit succeeds or fails completely and leaves the content of the repository in the intact former state [2]. Committing usually commits the changes of every element and its children. Adam wants to commit his new class PongBall. He selects the class in a SqueakSVN browser and clicks in its context menu on commit. This opens the "SqueakSVN Commit" dialog where he can enter a comment to the commit and all changes made to the element and its children are displayed. This dialog offers him a feature known as cherry picking. Cherry picking means that Adam can select only the changes he wants to commit. When he selects no change then all changes will be committed. He could select the class and only some of the methods of the class in the list of displayed changes and only the class and the selected methods will be committed. This way he needs to decide which parts of a project should be shared now and on which parts he wants to continue to work. Figure 2 shows a screenshot of the commit dialog with the commit field and the list of changes. Figure 2: SqueakSVN Commit Dialog When the commit happened the next step for Adam is modify. Especially if the part of the project he will modify has not changed in the repository since the last update. When Henry modified this part of the project then the working cycle is extended. This is discussed in section

8 4 Team Development A general problem that version control systems have is how they should manage the work of many developers working on one application. It is easy if the development is done in different parts of the system but in case that two or more developers want to work with the same code or file the tasks the version control systems face become harder. Assume Adam and Henry work together on another application in a programming language which uses source code files. They want to work on the same file and do this by loading it at the same time and modifying it afterwards. Adam finishes his changes to the file and sends his changes to the repository. Shortly later, Henry sends his changes to the repository and overwrites Adams changes. The consistency of the system can be corrupted this way if it comes to more files which depend on each other. Figure 3 is a graphic representation of the problem. Figure 3: The problem version control systems face This chapter has the purpose to introduce the reader to team development in SqueakSVN. Therefore information is presented about the two main concurrency models in version control systems and how they are used in Subversion and SqueakSVN. This information is necessary to understand the extended working cycle for team development and conflict solving in SqueakSVN. The last part explains the usage of the feature blame. 8

9 4.1 Lock-Modify-Unlock model A way to organize the access of many users to one file is by using the Lock-Modify- Unlock model. In this approach the repository only allows modification to a file to one user at a time by managing the access with locks. Again Adam wants to edit the same file. Before he can edit it he needs to acquire a lock for it and this is only possible if the file is not locked. He acquires it and then starts to modify it. In the mean time Henry wants to edit the file as well but he cannot access the lock and therefore cannot modify the file. The only thing he can do is to load the file. As a result he needs to wait until Adam sends his changes and or releases the lock. After that Henry can acquire the lock and continue to work on the file. 4.2 Copy-Modify-Merge model This model is a very common approach and a good alternative to the previous model. In this model Adam and Henry can work independently and parallel by making changes and then committing them to the repository. Only when they work on the same files or directories they need to update them before they commit their changes. Adam made his changes to a file while Henry already committed his changes to the same file. Then Adam needs to update the file and the version control system merges the changes Henry made to this file. This is done automatically but conflicts can occur and Adam is finally responsible that they are solved correctly. Adam receives a new version of the file after this process but it should only be committed after he verified if his changes work correctly with Henrys changes together. 4.3 Usage of these models Subversion has implemented the Copy-Modify-Merge model and the Lock-Modify- Unlock model [2]. Acquiring a lock for a file or a directory is possible but is especially necessary for binary files. Binary files cannot be merged effectively so a locking model is needed to manage the access to the file if more than one developer wants to modify the file. In Subversion text files are automatically merged when they are updated. A problem can happen when a modified text file in a working copy is updated. When the update is executed and Subversion tries to merge a line of a text file which has already been modified with new changes, a conflict can occur. A conflict needs a manual solution by the developer. SqueakSVN uses Subversion functionality and can use therefore principally both models. The usage of the Lock-Modify-Unlock model is not necessary because it does not handle binary files. It only uses the Copy-Modify-Merge model by mapping the semantic units of Squeak on text files and directories, and afterwards by merging them with Subversion. 4.4 Extended working cycle The extended working cycle has an essentially change to the basic working cycle as a consequence of the usage of the Copy-Modify-Merge model. There is another step 9

10 between commit and review called merging. This extended working cycle is shown in figure 4 for an overview. Figure 4: Extended SqueakSVN working cycle Assume Adam works now together with Henry on the GUI project. Both already started to develop and then Adam commits his work. Afterwards Henry tries to commit his work but the commit fails. Both modified the class PongBall and the commit fails for Henry because the class is out of date, then the merging step occurs. In this step Henry needs to update the class first and then the changes of Adam are merged automatically into Henrys working copy. If this changes create conflicts they need to be solved by Henry manually and this is covered in the next section. It is recommend for Henry to go one step back and to review Adams changes and to test if the new changes collide with his changes while the system is running. If they collide Henry should review and modify the code to solve the collision. The next step for Henry after committing is to update the whole project to continue to work with Adams changes. But it is recommend that he does this every time before committing. Because sometimes different changes in different parts of the system can still create failures when the system is running. This is associated with testing if the new changes collide with local ones. 4.5 Conflict solving If the conflict mentioned above occurs the local working copy becomes inconsistent. Then it is not possible for Henry to commit his changes. The most common conflict, which can occur, is a conflicted method. Assuming that Henry and Adam modified the method PongBall >>move then it is not possible to commit the whole project or this particular class. But other classes or methods which are not affected by the conflicted element can be committed. A conflict which is committed to the repository can create an inconsistent state in the repository and therefore this is not allowed by Subversion and by SqueakSVN. But Henry can solve the conflict. First of all the conflicted method, its class and the project are flagged with a conflicted icon. Henry can find the solutions for conflict by accessing the context menu in the Squeak browsers of the conflicted method. One 10

11 solution is using "resolve using mine" which overwrites the method with local modified code and the other solution is using "resolve using theirs" which overwrites the method with the methods code from the repository. Currently there are only this two radical ways of using "their" version or "mine" version. This is not an optimal way consequently an alternative was planned. This alternative is to use a kind of diff viewer which Henry can call on a conflicted method. It should not display only the differences but also the conflicts line by line in the methods code. Then Henry is able to modify the code manually and afterwards he can set the conflict to resolved. This way the local code and new code from the repository is merged in a proper way and nobody s changes are lost. 4.6 Blame view In the process of reviewing changes Adam and Henry want to find out who is responsible for a specific change when more developers join their project. The so called blame feature shows this information by presenting a table which displays which author changed which line at which revision. They can access it by clicking on the "view" button in the "SqueakSVN System Browser" and selecting "blame". 5 Code management in Smalltalk Since the beginning of Smalltalk ST-80 there were needs to version code and to share it over developer and computer boundaries. Many different ways of code sharing were developed since then and the most common ones in Smalltalk will now be discussed in the context of version control systems, team development and workflow with SqueakSVN. 5.1 Basic handling of Source Code in Squeak FileOut and FileIn code The simplest way to version or share Smalltalk code is to FileOut a class or method and later FileIn it. It is like exporting code and importing code. In every system browser there is an option in the context menu of a selected category, class, protocol or method to FileOut. When a FileOut is done a file is created which contains a textual representation of the exported classes and methods in the chunk format [3]. The opposite of a FileOut is a FileIn which can be accessed in different ways. The easiest way is to drag and drop the file into a running image and then a context menu pops up with a FileIn menu entry. At the end there are files which can be distributed between developers in different ways. Via mail, uploaded on a server or every other way files can be exchanged. This is the basic way of working with code between images. But this versioned code is only in one particular version. It is harder to exchange code and it takes time to get other changes into the image because when two developers change something in the same method one of this versions overwrites the other one. Or one of these developers merges 11

12 the two versions manually. This has to be done often if many developers work together. This way of exchanging code is only good to send someone code for review purposes Changesets in Squeak The changesets were first developed with the idea of team development in mind. But today they have other purposes because other applications are better suited for that purpose. This will be explained at the end of this section. Mainly changesets are a common way to keep track of changes to an image. Every image has a changes file which is extended by changes made to the image. Changes in classes and methods are saved in this file and also executed DoIts. A changeset is an ordered composition of these changes. Changesets exist not only for every image but also for every project in an image. This kind of project is not a SqueakSVN project. A Squeak project is a container for the state of a Squeak desktop, including all windows, as well the active changeset [4]. The changes of a changeset in Squeak are saved in the same format like FileOuts. The only difference is that they are not a snapshot of them but all changes which should be registered by them are saved in the order they will be made. So there could be the creation of a method and its deletion. The "change sorter" is the main tool to manage, manipulate or to use the changesets. There are two change sorter tools which can be accessed from the open menu in the world menu. The "simple change sorter" which displays only one changeset or the "dual change sorter" which displays two changesets at once and which can be used to compare, merge and to modify them both. This sorters provide functionality to select some changes and to apply these changes then to the system. This is a kind of cherry picking which was already discussed. The most important use is to have a backup of local changes to the image for the case that the image crashes. This way there is a chance to get the changes back into the image. The distribution of changesets is the same as with FileOuts because both of them are files which have to be distributed. Changesets have multiple issues like they cannot be shared effectively with many other developers. They are more a way to keep track of own changes not of the changes of many participates of a group. The work of two people who work together can be merged with the "change sorter" but with more developers the effort grows to merge and to prevent collisions of changes e.g. on one method. Especially the absence of an automatic merging makes it not effectively useful for team development. 5.2 Version control in Squeak with Monticello Monticello is currently the state of the art version control system for Squeak software development and is a part of most Squeak releases. The main management tool of Monticello is the Monticello browser, in which the developer can create a package and add different kinds of repositories. Also all reviews 12

13 of the history, diffing, merging, saving and loading of packages can be done from there [5]. Monticello generally takes a snapshot of the code at a particular time and creates a package out of it. It decides by a naming convention which classes and methods belong to a package. Every class which has a category name like the package name or which category name has a prefix like the package name followed by an "-" character is put automatically into a package. Also all methods which are part of a protocol which name consists of an asterisk "*" followed by the package name are added as extensions to the package. When a package is created it is necessary to specify its ancestors. Ancestors are packages on which the code of the new package is based. This means the code in the new package is either new or from an old packages. By reviewing the ancestors of a package and their ancestors the version history of a package can be inspected. The Monticello browser offers some dialogs to inspect this history and the changes made between different packages. But the user cannot inspect only a small part he has to inspect the whole package. If anybody works with Monticello the first step is to download the latests package from a repository. The next steps is making modifications, testing the code and saving it in the repository. This way a new package is put into the repository every time the code was changed and saved. When already another developer saved a package in the repository it is necessary to merge the new package into the local image, check if everything still works and then to save a new package. This is not useful for small changes or if the changes happen in different parts of an application e.g. in a business logic and in a framework. Therefore an application needs to be splitted in many small packages which are related to each others. This working cycle is similar to SqueakSVNs extended working cycle with the difference that updating is called loading, committing is called saving and the merging step occurs every time another developer has modified something. Monticello works with packages and for every small change a new package is created which needs to be merged by other developers. Therefore fine-grained working is not possible with Monticello The Package Universe Browser This particular browser is the main tool to share each others work in Squeak. It is used to publish finished releases to the public Squeak community that they could use them. The user has a system where he just selects what he wants to get into his image and all selected packages and their perquisites are installed automatically into the system. It is an easy way of distributing the code in a practical and easy manner for the end user. He just needs to search the packages he wants to install and installs them afterward. The browser can access many different so called universes. Each of them has different packages in it and is maintained by other persons. The best known one is SqueakMap. It tries to collect all important code which was ever written in Squeak. SqueakMap became the common way to register and to releases applications by packages to all Squeak users [6]. 13

14 These packages are Monticello packages and could be easily incorporated into the workflow of SqueakSVN. If Adam and Henry think that a particular revision of their project fits their specification for a release they can create a package with Monticello and published it via the package universe browser. This way the already established distribution ways of Squeak can be used to distribute stable releases of software developed with SqueakSVN. 5.3 Version control with ENVY ENVY is the dominant team development and configuration management system for the three main commercial Smalltalk platforms VisualWorks, IBM Smalltalk and Digital. It works on a central repository which is called the ENVY library. This library is a file which needs to be on a shared disk storage accessible for all developers. This section only scratches the basics of ENVY and its workflow. Especially its organization, version control model, role model, workflow and team development model Organization ENVY is basically organized in software components and the four main types of them are methods, classes, applications and configuration maps. They are similar to SqueakSVNs elements with the exception that there are no configuration maps. Applications are used to organize classes and methods into groups like in other version control systems which have packages, modules or SqueakSVNs projects instead. Versioned classes and methods cannot exists without an application. The controllers of a class are applications but ENVY supports also class extensions. A class extension is a method which belongs to a class and is versioned by another application which does not version the class to which the method belongs. Methods are the smallest software components and can be treated as separate components in the context of version control. The biggest software component is a configuration map. It contains all applications which create together a program and is a kind of list of all modules which are needed to use the program Version control Versioned software components can have different states. It could be in an edition state this means it exists as a copy of its ancestor and can be modified. An edition is identified by the time stamp which indicates the point at which it was created. It is automatically created by ENVY if somebody starts to modify a version but can be created manually as well. Another state is called a version which is also a copy but it could not be modified. It is identified by its name and is a freeze of development of an edition by converting the edition to a version. 14

15 5.3.3 Workflow Therefore there is a cycle between editions and versions. Editions are software components which can be new, in development and are not versioned. Versions are components which are named, saved, and not modifiable. All editions and versions are saved in the repository, but they are not published to other developers in this state. Versions can be released and in this process they become visible to other developers. In order to receive these new changes it is necessary to load the specific components. When this is done, the latest released version of the component and its sub components, which are not modified, is loaded into the local image. ENVY describes the development process as syncing up. The first step is to write some code, the next step is to test the code and the last one is to version it. Before testing the code it is recommended to load the most recent code from the repository and test again for collisions with other people s changes. Then if there are no collisions the code can be released. Both actions releasing and loading are similar to SqueakSVNs commit and update. Therefore there is a similar working cycle like in SqueakSVN. There is modifying local code, reviewing it, committing it and if it is necessary updating it. The big difference is that merging does not happen because ENVY has a specific role model which is addressed in the next section Team development There is a specific role model in ENVY. Every class has an owner who decides which released versions are accepted and which denied. On the other hand there are class developers who are allowed to change a class but the owner has still the responsibility to manage the changes of his class. Hence they can not release a version only the owner can do so. If there is more then one version of a component in a class the conflict solving is made by the owner manually. In the bigger scope there are application and configuration map managers. They just have an administrative role of managing the consistency of their components. This happens by releasing versions of the components when they think the component is in a stable state. Only the library supervisor has other responsibilities than managers. He is the owner of all system classes and therefore the only one who can change them e.g. with an extension. He is also the only one who can manage user, applications and configuration maps. Section 25.2 gives more information about features and specifications on ENVY. Also the book "Mastering ENVY/Developer" [7] is a good reference regarding these topics. 5.4 Version control in VisualWorks with StORE StORE is an add in component of VisualWorks which provides version control and team development features. 15

16 It uses a central code repository which can use different kinds of databases as a back end but can be used offline as well. Online functionality is only necessary for the distribution of changes Organization In VisualWorks classes and methods are saved as so called definitions. These definitions are basically organized in packages and bundles. When StORE is added they become versionable. A package contains definitions and a bundle groups packages together. All packages which belong together like frameworks etc. are grouped that way and form an application [8]. When a package is in a stable state to be released it can be saved as a parcel. A parcel is a package as a file for distribution. Some general modules like core components in VisualWorks are saved as parcel files therefore a developer needs to load them first before he can start to develop an application which needs them Version control A package or bundle in the repository is known as the parent version. When it is loaded into an image it is called a working version. It can be modified without modifying the parent version. Saving this version in the repository creates a new version where only the changed definitions of this package or bundle are saved. It is labeled with a string which identifies the version and usually this string consist only of the version number or additional information e.g. release candidate (RC X). Bundles work as a container for packages therefore loading or publishing them is executed for all their packages. All modified packages of a bundle will be published automatically when the bundle is published Workflow In StORE exists a similar working cycle like in SqueakSVN. There is a loading step where the package or bundle is loaded from the repository. There is a modifying step where the code is modified in the working image and then there is a publish step which send the changes to the repository of StORE. This working cycle is also extended by a merging step. For this purpose StORE offers a merge tool to merge different versions. The merging step does not occur in every cycle it is done when two developers modify the same package or bundle. They create this way two new versions of the same component in the repository which have the same parent version. These two lines of development need to be merged later Team development Additionally to version control StORE has a team development feature known as blessing levels. A component can have different blessing levels which support the coordination in the software development processes by informing the developers about the status of the component. This levels could be "Work in Progress", "Development", 16

17 "Published", "Merged", "Tested", and "Released". They are set when a version of the component is published. There is another level not mentioned called "Integrating-Ready". This level is usually used to signal that merging of different versions of one component is now necessary in the development process. This is done by using the merge tool which collects all versions which need to be merged and merges them to a new merged version. This merging can be done by any developer and needs to be published afterwards. In this process conflicts can occur which need to be solved manually. The creation of more than one line of development has the limitation that fixes and changes are only available in a particular line as long they are not merged. Therefore more team coordination is needed to prevent that the same bug is fixed twice or a feature is implemented by two developers. For more information about features and specifications on StORE see section Evaluation There are many ways to share code in Squeak, FileOuts, changesets and Monticello packages. Especially FileOuts are a way to share code and contain no version control and team development support. When it comes to changesets they offer a bit more. They contain different stages of code and offer team development with the change sorter. But their team development capabilities are limited to a low number of developers. Developers really need code management systems which support version control and team development as central aspects. Currently this tool is Monticello which is a full version control system but it has some downsides compared to SqueakSVN. SqueakSVN allows developers to work simultaneously and distributed on the same project without interfering to each others work. This is possible because of the usage of the Copy-Modify-Merge model which allows a detailed view and a way to work with single elements. ENVY has also a similar fine-grained view and both systems allow working on the whole system or just on a particular part of it therefore developers can work parallel and are not affected by each other. Except their work overlaps then both programs react different. SqueakSVN offers merging and when conflicts occur appropriate team development features to solve them. ENVY rather uses a code ownership model where conflicts cannot happen and the owner decides which changes are accepted. This fine-grained working is part of the already mentioned feature cherry picking. On the contrary Monticello and StORE are package based and do not have such a fine-grained view on the system. Such detailed view can only be created when for every class a package is created. In Monticello for every small change a package is created and it is necessary to merge every new package into the image to be able to send changes to the repository. StORE does not have this limitation but merging is later necessary for all development lines which were created during the development process. To prevent this behaviour an application need to be splited in many small packages. In comparison developers in SqueakSVN and ENVY only have to merge when it is necessary. 17

18 In all of this version control systems there is a similar working cycle. There is first a phase where the latest code is taken from the repository, then this code is modified and as the last phase the changes are send to the repository. Only when merging is necessary their working cycles differ. Accordingly to the evaluation SqueakSVN has combined interesting features for a Smalltalk development system, with the help of Subversion. There is a fine-grained view on the development process which allows an easier and faster development for developers. It also implements a kind of working cycle which is already used effectively in many other Smalltalk version control systems. But it also enriches Smalltalk with a new feature for team development. Cherry picking which is not supported by any other Squeak version control system. Not only because of the fine-grained view but also because of the consequent use of this feature in the tools where the user is able to select and work with single elements. 6 Tool support This section gives the reader an user specific view on the many tools which were developed to integrate the workflow and team development features SqueakSVN offers. 6.1 The Project Browser The "SqueakSVN Project Browser" is the main management tool for SqueakSVN where developers can create new projects, inspect revisions and inspect changes of versioned elements, apply SqueakSVN functionality on them and manage the project. This browser is accessible through the open menu in the world context menu by clicking on "SVNProjectBrowser". In order to browse any versioned class or method with the "SqueakSVN System Browser" it is necessary to click on the representation of a versioned class or method and select in the context menu "browse class" or "browse method". The browser consists of three different columns. The first column is a tree which shows all SqueakSVN projects in the image and displays their current state. The state is indicated by an icon in front of the name of the element. The state can be either unchanged, added, modified or conflicted. The second column consists of two parts. The upper part is the revision list which show the available revisions where the selected elements in the first column changed in the project history. Each of the entries has a short summary in which is explained who changed it and when. If the user needs to update the revision list he can hit the "Refresh" button in the lower right corner. The current revision of the selected element in the first column is displayed in a bold font. If a revision is selected the comment of the selected revision is shown in the text field under the revision list. In the third column a summary of changes is displayed. It shows what happened between the selected revision and the head revision. If no revision is selected the third column shows the changes between the current revision of the project and the head revision. Figure 5 shows a screenshot of the browser. 18

19 Figure 5: The SqueakSVN Project Browser 6.2 The System Browser The SqueakSVN System Browser is a modified standard browser. It extends the standard browser with additional SqueakSVN functionality. It displays the current state of versioned classes and methods with an icon in front of their name. The state could be unchanged, added, modified, conflicted or no icon is shown. If the context menu is opened, on such an element, there will be an SVN sub menu which contains all for this element applicable SqueakSVN commands. The browser can be opened by selecting "SVNSystemBrowser" in the open menu of the world menu. Figure 6 shows a screenshot of the browser. An additional feature is a text field in the upper part of the browser where the current SqueakSVN project can be selected or changed. This selection field is important because all changes which are made will be applied to this current project. The current project can be changed in two ways. First by entering a name of an existing project or by calling the context menu of the text field like shown in figure 7. Then all in the image existing SqueakSVN projects are listed and one of them can be chosen to change the current project or select no project to disable the filter. This is important as the icons shown in the browser are only shown if their element belongs to the current project. Additionally clicking on "Browse current project" opens the "SqueakSVN Project Browser" with the current project as the selected one. 19

20 Figure 6: The SqueakSVN System Browser Figure 7: The SqueakSVN System Browser showing the current project selection 6.3 The Diff Viewer For team development SqueakSVN has the diff viewer which displays changes between two revisions. If an element is selected in the "SqueakSVN Project Browser" the viewer can be accessed by selecting a revision in the revision list and clicking on "diff..." in the context menu. This opens a menu which shows all available revisions for the selected element. After that the diff viewer is started and displays the changes made between the start revision and the target revision. The start revision is the selected one in the revision list and the target revision is the second selected revision. Figure 8 shows the diff viewer diffing two revisions. 6.4 The Repository Browser This browser can be accessed from the "SqueakSVN Project Browser" by opening the context menu on a selected revision in the revision info list and selecting "browse revision". It was created to help developers to inspect the history of a project. By using this browser it is possible to take a look in every stage of the developed project by displaying the content of the repository at a particular revision in a read only System Browser. 20

21 Figure 8: The SqueakSVN Diff Viewer diffing two revisions This state of the repository can be browsed like an ordinary browser which shows only the versioned elements. A class category, a class, a protocol and a method can be selected. The selected method or selected class is shown if selected. 21

22 GUI architectures and tool support of SqueakSVN 7 Introduction User interfaces (UIs) are important components of software applications. UIs offer the possibility to control the system and to change the state of the system, accordingly to the interaction a user made. A graphical user interface (GUI) is the graphical representation of an application, which receives the user input and displays the output on the screen. One of the first GUIs, a pointer-based system called Sketchpad, was developed in 1963 by Ivan Sutherland. Today GUIs are much more complex but still designed to receive the user s input, forward it to the domain logic of the system and accordingly to the input change the state of the system. The usage of a GUI enhances the efficiency and usability for the underlying domain logic and functionality. Based on the definition of Jürgen Döllner, Professor of the research group "Computer Graphics" at the Hasso-Plattner-Institute, Potsdam Germany: "A graphical user interface is a software system, which creates and administrates an graphical-interactive user interface.". The GUI should be designed in a way that it can perform the purpose it was build for. Squeak is an established Smalltalk development environment, so that advanced users should have only minor changes in their standard workflow of developing software applications. It is possible to reduce the time to introduce an user to SqueakSVN, with easy and intuitive usable tools, to a minimum. The standard workflow of SqueakSVN is described in the section 3. It describes, how a developer can access and work with SqueakSVN. The new tool set has to provide the Subversion (SVN) functionality, but in a intuitively way. The major part of this elaboration delivers to standard GUI architectures, introduces the possibilities to create GUIs with Squeak and presents implementation details of the GUI of SqueakSVN. The second part of the elaboration is about the tool integration and implementation of SqueakSVN. 8 GUI architectures In general, GUI architectures are useful to avoid mistakes in the application design. "Looking at it from a design perspective they represent a particular set of problems in system design - problems that have led to a number of different but similar solutions." [9]. The solutions are transferred to design patterns for GUI architectures. A well designed GUI should be easily exchangeable and enhance the usability of software applications. Usability is the dimension, how "[... ] the design of a particular user interface takes into account the human [... ] psychology or physiology of the users, and makes the 22

23 process of using the system effective, efficient and satisfying." [10]. Usability describes how well a software product can be used for its intended purpose. In the history of designing new IT-Systems, the developers worked out many solutions to avoid common mistakes and to develop flexible, easy to maintain, and reusable applications. Therefore applications are splitted in three basic components: the presentation layer, the domain logic, and the data access layer. The presentation layer is responsible for displaying the elements of an application. It receives the user input and refers it to the domain logic layer. Additionally, the presentation layer also gets the data from the domain logic layer and displays it as output. The GUI belongs to the part "UI-Components" of the presentation layer is displayed in figure 9. The domain logic layer executes all the functionality of an application. It receives the input from the presentation layer and operates accordingly to it. After the calculation it sends the result to the presentation layer for visualization of the output. The data access layer defines storage mechanism and accesses the needed data, e.g. from a database. The layered architecture of figure 9 led to the desired result, that the GUI is independent from the business logic. To separate the user interface from the business logic has the advantage, that there are no strong bindings between them. Accordingly, it is possible to exchange the GUI easily by another. Certainly every graphical presentation can be exchanged, but with one designed by GUI architectures, there should be no or only minor changes to the business logic. A software application without a graphical representation has less usability for an unknowing user than an application with such a representation. There is no visual help for the user to find the functionality he is looking for. The user has to read a manual, which could take a long time to understand and operate with the application. "Nevertheless, good user interface design relates to the user of an application, not to the system architecture."[11]. This citation clarifies, that the user needs an intuitive GUI for easy and comfortable usage of the software product without a long learning process. There exist some GUI architecture patterns for designing efficient and effective GUIs. A design pattern is an approach for general and common problems. A pattern does not only describe a particular set of problems, it describes also a solution for this problem and why the solution is a good one. So patterns are really helpful in the software development process, because a developer needs not to invent and create everything on his own. He can use the patterns, which turn out to be good solutions. One of the most common patterns for designing a GUI is the Model-View-Presenter 23

24 Figure 9: Standard layered architecture of applications (MVP) pattern (see section 8.1), which description is based on Martin Fowler s paper "GUI-Architectures" [9]. 8.1 Model-View-Presenter The Model-View-Presenter pattern is a software pattern, which appeared in the 90s. But today the definition of Martin Fowler from 2004 is the crucial factor. In MVP addresses model and view to be completely separated. They are connected over a presenter. The model presents the logic of the view. It is controlled by the presenter, but is not depend on view or presenter. The view has no flow logic, but it is able to instantiate the presenter object and provide a reference to it. The view is responsible to display the in- and the output, but has no direct access to functionality of the presenter. The presenter is a connection between the model and the view. It controls the logical flow of the model and view, to make sure that the view is conform to its functionality. 24

25 Like shown in figure 10, the view provides event methods to inform the presenter of changes. MVP has two interfaces for the view and two interfaces for the model. The interfaces of the model are used for getting and setting data to and from the model with the presenter. The presenter connects the two interfaces and assists for the reusability of model and view. Figure 10: Model-View-Presenter There are many different implementation for MVP and each of them has different implementations for the model. This variations is the main factor, why the model depends differently strong on the other components. Martin Fowler defined three different patterns for it in his paper "GUI-Architectures" [9]: Passive View, Supervising Controller, and Presentation Model. The following sections are about this definitions of Martin Fowler The Passive View In the Passive View pattern exists no connection between model and view for an independent data-model. The presenter synchronizes the data between both of them. Additionally, the view implements only logic for the presentation, no synchronization of data is needed (see the architecture in figure 11). The advantage of the Passive View is the enhancement of the testability, because only simple source code is available for in- and output of the presentation. The view is replaced by copies for the tests, that it is possible to test the functionality without involving the GUI. No important logic is in the view, because the source code is tested for synchronization in the presenter. 25

26 Figure 11: The Passive View The Supervising Controller In the Supervising Controller the view is responsible for a simple data synchronization. The mechanism is based on data-bindings. The presenter controls the flow between model and view. It uses this technique to make sure that the transmission of the data-bindings between model and view is successful. The view synchronize itself over these data-bindings. When data is changed by the view, the model can access the data changes over the data-bindings. The figure 12 shows this architecture. Figure 12: The Supervising Controller The advantage of the Supervising Controller is the simple handling and administration. This implementation of MVP has less need for synchronization because of the mentioned data-bindings between model and view, which results in less source code The Presentation Model In the Presentation Model the model is really designed for (and thus is part of) the presentation layer. This is the main difference to all other implementations of MVP. The model represents the behavior and state of a view, without getting involved with any of the graphical conditions. The view represents a projection or a rendering of the model onto the screen. It observes the model and updates by implicating possible 26

27 changes of it. View state and logic are both extracted from the view into the model, see figure 13 Figure 13: The Presentation Model The advantages of the Presentation Model are the possibility of testing the system without involving the UI. The support of some forms of multiple views and a separation, which may make it easier to develop the UI. It allows a developer to write logic that is completely independent of the views used to display. A disadvantage is the needed synchronization mechanism between the model and the view. Although this synchronization can be very simple. The three implementations have three different goals. A developer of a GUI is able to select the implementation which provides the best solution according to the problem or task definition. 9 GUIs in Squeak Squeak has two completely independent user interface frameworks, each with its own window system: MVC and Morphic. MVC is available inside MVC projects and is nearly an exact implementation of the Model-View-Controller pattern. Morphic is a newer implementation which is geared to the Presentation Model of MVP. "Most of the standard system windows can be opened in either framework, but media support is more highly developed in Morphic." [12] The following sections will give a brief introduction for these two components of the GUI frameworks of Squeak. 27

28 9.1 MVC MVC means Model-View-Controller, and is one of the oldest graphic architectures or user interfaces in Smalltalk. It is based on the idea that "[... ] any object should be easily and immediately accessible to the user." [13]. Additionally, it gives the user the possibility to build flexible UIs for any object. The following descriptions of the MVC components depends on "Applications Programming in Smalltalk-80(TM): How to use Model-View-Controller (MVC)" by Ph.D Steve Burbeck [14]. "In the MVC paradigm the user s input, the modeling of the external world, and the visual feedback to the user are explicitly separated and handled by three types of object, each specialized for its task."[14]. These objects are the model, the view and the controller. A model can be any object in the system. The user is aware of this object. The model does not need to know about the graphical conditions or user interactions, all this is done by the view and the controller. The view is responsible for the visual representation of the model, which the user is able to understand. It manages the graphical and the textual output and represents it on the display allocated to this application. The controller takes the user s input like keystrokes or mouse movements and clicks, interprets the inputs and informs the model and/or the view to change in the appropriated state. Additionally, the model manages the behavior and data of the business domain. It responds the view, which requests its state, and behaves accordingly to the controller, which instructs the model to change state. This formal separation in model, view and controller is an important notion, because the behavior is "[... ] inherited, added to, and modified as necessary to provide a flexible and powerful system."[14]. The MVC framework is still available in the Smalltalk programming environment and may perform better, corresponding to Morphic, on slower machines or when the memory is extremely limited. 9.2 Morphic MVC has the disadvantage, that the GUI for each application is very complex, because model, view and controller have to be defined clearly. Morphic deals with these grievances and is more powerful. It has its focus on current development and some of the interesting facilities (like end-user scripting), which only work with Morphic. It is a framework for building interactive graphical objects, called morphs. Morphs can be built both interactively (by direct manipulation) or by Smalltalk code. The original MVC implementation in Smalltalk made it possible to build general and flexible user interfaces for any object, but it did not make it easy. A very good thing in Morphic is, that it is easily and open end extensible. "This makes Morphic the ideal environment to experiment, learn and write new styles in user interfaces, breaking away from what commercial programming tools allows us to do. [... ]" [12]. Morphic realizes also the idea of any object being visually accessible by the user, but 28

29 it is much simpler and easier than MVC. Morphic was developed by John Maloney and Randy Smith as UI, which works with morphs. A set of morphs are already included in Squeak as direct-manipulation UI construction kit. These objects know how to react on the user interactions, and how to render themselves on the screen. The name morph is Greek and means shape or form. Morphic is completely written in Smalltalk, so that there are no restrictions to how a morph will appear and react. The basic idea is to combine the functionality of the model and the view from MVC in a single morph object. This object has to execute the business logic like the model and also knows how to react on user interactions. That is why a controller is no longer needed. Some standard elements in a Morphic GUI are its subclasses SystemWindow or the StandardWindow, which inherit the behavior and all the messages of the superclass. Morphic includes also some uncommon morphs like the CurveMorph, the FishEyeMorph or the MovieMorph, to mention only some of them. It does not allow multiple views on the same model, but if this is a desired features the developer has the possibilities to create a non-morphic object for a model and a morph for the view, like MVC does. A composite is a morph, which is composed of submorphs. When such a composite morph is moved, copied or something else, all its submorphs are moved, copied, or something else, too. A composite morph behaves like a single unit. One of the disadvantages of Morphic is, that it don t scale to complex problems. The morphs are too abstract for big applications. This problem is solved with the invention of pluggable morphs. The pluggable morphs inherit from the superclass PluggableMorph. They take a model, when they are constructed. This model can be any object of the image, like in MVC. The model knows how to interact with the user and represents the behavior and state of the view. The view are the pluggable morphs, which observes the model. Pluggable morphs are oriented to the Presentation Model pattern of the MVP. 10 The GUI architecture of SqueakSVN SqueakSVN supports two kinds of tools. The first group of tools is constructed with the ToolBuilder. "The Tool Builder is a simple framework to achieve cross-ui-framework (MVC, Morphic, Tweak) support for a limited number of widgets which are critical for various Squeak tools [... ]." [15]. The second group of tools is a subclass of the OBSystemBrowser, which belongs the Omni Browser framework. "Omni Browser is a ground up rewrite of the classical system browsers provided in Smalltalk. It s designed to flexible and extensible, so as to encourage experimentation with new types of development tools, language extensions, and runtime environments." [16]. Implementation details of the tools are described in the section 11. The tools mentioned here belongs only to the first group of tools, which are created with the Tool Builder. The second group is not mentioned here, because the architecture of the Omni Browser framework can be read in the paper "Meta-Driven 29

30 Browsers" by Alexandre Bergel, Stephane Ducasse, Colin Putney and Roel Wuyts [17]. The GUI architecture of the SqueakSVN is described here with "SqueakSVN Project Browser" how the architecture interacts. The tools created with the Tool Builder uses a variation of the "Presentation Model" of MVP. The Tool Builder is included in Squeak since the 3.8 image. The specifications in SqueakSVN used for the despription of the morphs creates only pluggable morphs, without exception. These pluggable morphs take a model, which can be any object of the system. The morphs are part of the view, because they are responsible for the presentation, like the diff- and blamemorph. The "SqueakSVN Project Browser" uses morphs for their presentation. The PluggableTreeSpec is a specification for a morph to display the versioned entities of the image with SVNNodes. These nodes are used for the representation of the versioned entities. SVNNodes are similar to the OBNodes of the OmniBrowser framework and are described in the section A user can interacts with the nodes and causes the models to change their state. Each node belongs to a SVNElement. SVNElement are the versioned entities in SqueakSVN and are described in the section The SVNNode is also part of the view, because they represent the versioned entities. In Squeak the user can interact with the selected nodes in the morphs of a browser. The interaction with the nodes is defined by using the context menus. These menus depends on the selected node. For example a selected SVNClassNode has a class context menu. These menus provide actions for the user to change the state of the element, which is represented by the node. To change to state of a node, Subversion functionality has to be executed, like committing or adding. When a user clicks on a menu entry in the System Browser, the corresponding command is executed. The SVNCommands are part of the presenter and also of the model, because they implement a little bit of the domain-functionality and react according to the user s input. In consideration of the fact, that they primarily should provide an action they belong more to the presenter. SVNCommands are similar to the OBCommands, an implementation of the Command-Pattern, mentioned in section Commands are called by the selected nodes. The models are everything which can be addressed from the workspace, like the SVNElement, or in some cases the SVNNodes. The nodes belongs also to the model, because they implement some kind of the domain logic. The domain logic is the Subversion functionality, which is implemented in the SVNElements and executed on SVNFiles. The SVNEnvironment has some tasks of a controller. The environment is responsible to synchronize the model and the view or more precisely the SVNElements and the SVNNodes. It records all changes the user made and gets the needed and available projects or elements to execute the #changed commands on them. This message updates the morphs and nodes, to present the changed state of view. The view is updated according to the changes of the elements, the morphs and nodes. Nodes, which knows its corresponding element send a "self changed" message to the "SqueakSVN Project Browser" to update each morph of the browser. SqueakSVN has no clear implementation of one of the pattern. The model is also responsible for some parts of the presentation. SqueakSVN is some type of the MVP s 30

31 Presentation Model, which is described in section 8.1. These standard architecture is visualized in the figure 14. Figure 14: The basic architecture of the SqueakSVN UI 10.1 SVNElement A SVNElement is a container for the objects which are versioned with SqueakSVN and provides its functionality. SVNElement is the superclass for SVNProject, SVNClass and SVNMethod, which inherits the Subversion functionality. Every class or message in Squeak, which is under version control has a corresponding SVNClass or SVNMethod. SVNElements can execute the domain-functionality, like committing, updating, deleting and so on. The elements are described in detail in chapter?? SVNNode The SVNNodes provide the functionality, which the tools need. Additionally, they are part of the presentation. Each SVNElement has its equivalent SVNNodes. SVNNodes have the same behavior like OBNodes which are responsible in the Squeak tools for the presentation. There exists multiple types of SVNNodes, because they correspondent to the elements: SVNProjectNode, SVNClassNode, SVNMethodNode, 31

32 SVNProjectMethodNode, SVNCommentNode, SVNClassSideOfClassNode and SVNInstanceSideOfClassNode The user can access the Subversion functionality by interacting with these objects, e.g. commit or update. This interaction can be done textual with the workspace or by interacting with the elements of the view, the nodes. The SVNNodes receives the change-events and informs the SVNElement about system changes. Actually, the OBNodes receives the user s input and forwards it to the SVNNodes. The nodes are oriented to the Omni Browser framework SVNCommand The SVNCommands are similarly implemented to the command-pattern. A command object is responsible to represent an action. It includes an action with its parameters. The usage of commands separates the domain-functionality from the presentation. A command is triggered, when the user selects in the context menu of a SVNNode some Subversion functionality, which means that every context menu entry is connected to a command especially to a SVNCommand. The SVNCommand >>isactive message defines when the command can be executed. This message is implemented in each subclass of the SVNCommand. The execution is defined in SVNCommand >>execute message, which is defined in each subclass of the SVNCommand, too. The commands can manipulate the elements and change their state. They provide actions for nodes and different browser views. Because of that they are parts of the model and of the view, too. But mainly, they represent an action and are more part of the view SVNEnvironment and SVNRegistry The SVNRegistry creates browser environments for the "SqueakSVN Project Browser" and the "SqueakSVN System Browser". The SVNEnvironment takes a collection and SVNRegistry takes a set of SqueakSVN projects, when they are created. The registry creates a SystemChangeNotifier when it is initialized, which receives the changes a user made to the system. SVNRegistry sends the SVNRegistry >>notifyaboutsystem- Changes: message to notify the system when: a class is removed, the #classremoved: message is send, a class is modified, the #classchanged: message is send, a class is recategorized or commented, the #classdetailchanged: message is send 32

33 a method is modified, recategorized, reorganized, renamed, or commented, the #methodchanged: message is send,or a method is removed the #methodremoved:message is send. The SVNEnvironment answer requests of the SVNRegistry which class or method is affected when the registry sends #notifyaboutsystemchanges:message. The architecture of change notification is shown in figure 15. Figure 15: The change notification in the tools 11 Tools of SqueakSVN SqueakSVN is integrated in the Squeak development environment with tools. These tools help the developer to use the SqueakSVN functionality, without writing every command in a command line client for execution. The usage of SqueakSVN brings only minor changes in the standard workflow of a developer, that he just needs a brief introduction to use the tools and their functionality. The tools are easy and intuitive to use. SqueakSVN extends the System Browser and includes some completely new browser, which are constructed by using the Tool Builder (see section 10). One interesting component of the ToolBuilder is the ToolBuilderSpec and all its subclasses. These classes, the PluggableWidgetSpec, PluggableMenuSpec or PluggableMenuItemSpec are components of each GUI description made with the Tool Builder. They have a few subclasses for differently tasks, e.g. the PluggableTextSpec, the PluggableListSpec or the PluggableButtonSpec. Most subclasses of Tool- BuilderSpec inherit the SVNTool >>buildwith: message, which is responsible for creating the corresponding part of the GUI. The specification describes how the tool 33

34 should look like. The #buildwith: message takes differently arguments, according to the desired functionality of the ToolBuilderSpec subclasses. The Tool Builder provides the possibility to give an abstract description of a GUI with the Tool Builder specifications. These general specifications create the framework specific morphs for Morphic, Tweak or MVC. Using this abstraction of specifications, the Tool Builder is framework independent (see figure 16). Only the ToolBuilder can Figure 16: The main components of the Tool Builder access the framework dependent parts of the presentation. The user can not influence this directly, he just has to handle with the Tool Builder and its specifications. If these specifications are defined, the construction of the desired tool is done accordingly to the specific framework of the system. To create the tool the Tool Builder replaces its specifications with framework dependent morphs or MVC elements. The alternatives to the usage of the Tool Builder are: to use the Morphic framework, or to create an own tool builder. Using Morphic is very difficult, because every detail has to be hard coded in SqueakSVN. The usage of Morphic is reasonable for non-complex applications. Complex problems do not perform well. The advantage of these option is a flexible design, which is framework depend. The implementation of an own tool builder is very time-consuming because every special case have to be considered. Morphic is too abstract for complex problems. Both implementations has the disadvantage, that each element have to respect the Model-View-Controller concept of Squeak. "Monticello", a version control system of Squeak, uses the ToolBuilder only for the specifications and builds its tools with the class MCToolWindowBuilder. These classes instantiate the Monticello builder and describe most of the morphs with the ToolBuilderSpecs. But it also extends ToolBuilderSpecs, when a needed morph is not available. For example there exists no PluggableTableMorph. The Monticello builder extends the ToolBuilderSpec to represent a table. With this solution "Monticello" is framework independent, but more flexible then the Tool Builder. 34

35 The usage of the Tool Builder was a really simple design decision, because it is easy to use and very manifold. Mainly, SqueakSVN is framework independent because it uses the Tool Builder, although it has to be installed in the image. A disadvantage of the Tool Builder is that its further developement is very slow. There exists an integration of the UI-Enhancements in the ToolBuilder. "UI Enhancements provides support for selectable user interface themes in Morphic, extra widgets to support a consistent look-and-feel and a framework for easily creating UIs in code." [18]. These integration has a new subclass for the MorphicToolBuilder, the PSToolBuilder, which integrates the UI-Enhancements. The UI-Enhancements are available in the "Universes browser" in the category "User Interface" or for download the Monticello packages from UI Enhancements page on squeak source [19]. The following sections describe some implementation details of these tools The SqueakSVN Project Browser The "SqueakSVN Project Browser" is a tool to administrate and to manage software elements which are under version control. It displays and observes the state of all versioned objects. It can create and display a working copy in a compact representation, and visualizes its content. Also the SVNProjectBrowser could display the status of objects and allow the direct access to Subversion commands and SqueakSVN features. It is completely constructed with the Tool Builder framework. This framework is described in detail section 10. To open the "SqueakSVN Project Browser" causes the SVNRegistry to build a SVNEnvironment with the existing SqueakSVN projects. The Tool Builder sends the SVNTool >>buildwith: message to define how a tool should look like. The "SqueakSVN Project Browser" creation is described here in detail, as example how the Tool Builder works. Executing the "SVNProjectBrowser" command in the "open..." menu, initialize the "SqueakSVN Project Browser" with a SVNEnvironment. The environment is created by the SVNRegistry and adds all SqueakSVN projects as dependents. Afterward the SVNProjectBrowser instantiate the ToolBuilder, if no instance already exists. The Tool Builder detects its responsible framework-dependent subclass to execute the ToolBuilderSpec >>buildwith:message. When the UI-Enhancement integration is installed, the used framework builder is the PSToolBuilder. This message is only implemented in the superclass of the SVNProjectBrowser, the SVNTool. It chooses the correct framework dependent tool builder and sends the SVNTool >>buildmainwindow message to create the specific morphs. This message creates the hole body of the "SqueakSVN Project Browser" and is shown in figure 17. The message describes a PlugableWindowSpec, which creates a browser window. It sets a model for the main window, which is an instance of the PluggableWindowSpec. The model is a subclass of the ToolBuilder, which depends on the used framework, with the installed integration the model is the PSToolBuilder. The SVNTool >>extent message sets the size of the window and SVNTool >>label message set the displayed name and the title of the tool. These messages are defined for each sub- 35

36 buildmainwindow self builder pluggablewindowspec new model: self; extent: self extent; label: self label; children: self buildwidgets; yourself. Figure 17: The SVNTool>>buildMainWidget of the class SVNTool class of the SVNTool class, too. The interesting functionality is in the line: "children: self buildwidgets;" of figure 17. The SVNProjectBrowser >>buildwidget message causes the main window to create the six submorphs. The first is described in the SVNProjectBrowser >>buildsvnelementtree message, which sets the specification for the panel on the left side of the browser. This specification conforms to the number 1 in figure 19. The SVNProjectBrowser >>buildrevisioninfolist message conforms to number 2 in the upper middle panel of the same figure. The SVNProjectBrowser >>buildlogmessagetext conforms to number 3 in the lower middle panel, and SVNProjectBrowser >>builddiffsummerizelist conforms to number 4 the panel on the right. The two buttons of the "SqueakSVN Project Browser" are described with the SVNProjectBrowser >>buildbuttonsfromcommands message. This means that the "SqueakSVN Project Browser" depends on six specifications and is therefore a composite morph. buildsvnelementtree self builder pluggabletreespec new model: self; roots: \#updateprojectnodes; haschildren: \#nodehaschildren:; getchildren: \#getchildrenofnode:; label: \#labelofnode:; menu: \#menuonsvnelements:; getselectedpath: \#getpathtoselectednode; icon: \#geticon:; setselected: \#setselectednode:; frame: 0 corner: 0.9); yourself Figure 18: The SVNProjectBrowser>>buildSvnElementTree message Figure 18 gives a detailed view of the implementation of the submorph description of the tree view. The SVNProjectBrowser is the model of the specifications and passes the selectors to itself. The selectors provide the information, where the "SqueakSVN Project Browser" can get the needed messages. Each message with the prefix "#" is a selector. The selectors are used by the model for its own presentation. The figure 19 of the "SqueakSVN Project Browser" is used to describe the general ar- 36

37 chitecture. The PluggableTreeSpec on left side of the browser (number 1 in the figure) is the description for the needed morph. The morph which is generated by this description displays an organization structure of the versioned elements. Each SqueakSVN projects has its own associated root node, a SVNProjectNode, in this panel. Direct children of the root node are SVNClassNodes and SVNProjectMethodNodes, a container for extensions. Extensions are methods which are added to a project without its class. Each class node has the children SVNCommentNode, SVNClassSideOfClassNode and SVNInstanceSideOfClassNode. The two mentioned last can have SVNMethodNodes as their own children accordingly the instance and class methods of the class. The nodes are required to display the versioned elements and belongs to the view. Each node displays a state icon. State icons display the current state of a SVNElement and are described in the section The nodes provide context menus which depend on the selected element. For example, a selected class has a class context menu which is different to the method context menu of a selected message. With the context menu the user can access the Subversion functionality, which is executed for a node and all its children, the subnodes. If a user clicks on the "commit" entry in the context menu of a class, the "SqueakSVN Commit Dialog" pops up. It is described in section After adding a log message to the commit, a new revision is created for the selected class and all its methods and other children, if they have changed. This is done with the SVNCommitCommand. Another description for the "SqueakSVN Project Browser" is the PluggableListSpec (see number 2 in the figure 19) in the upper middle panel of the "SqueakSVN Project Browser", which depends on the selected node in the PluggableTreeSpec. It displays a commit log for each revision, in which the selected node is added or modified. The commit logs are the result of a SVNInfoRequest and are composed to display the revision number, the author and the time stamp when the revision was created. The actual loaded revision is shown in a bold font. Selecting a commit log of a revision, causes the PluggableTextSpec, in the lower middle panel (see number 3 in the figure), to display the log message of the revision it depends on. The log message can be added to each commit. When a project is created, a first log message is generated automatically. The panel shows the header "Log-Message:" in a bold style and in the next line the log message of the commit. Additionally, the PluggableListSpec on the right of the "SqueakSVN Project Browser" (see number 4 in the figure) describes a summarize of each change made between the selected revision and the head revision by using the SVNDiffSummaryRequest. The nodes in the specification provide a context-depending menu to access the Subversion functionality with commands. The SVNCommands are similar to the OBCommands. If such a command is triggered, it send the Morph >>changed message to the browser, which causes to update all panels of himself. The commands execute also the needed functionality, like the commit functionality if the "Commit class" command is hit, for example. It opens the "SqueakSVN Commit Dialog", which components are created with the Tool Builder and are described in the section The "Create Project" button is described with a PluggableButtonSpec, which causes to open the "SqueakSVN Create Project Dialog". This dialog is created with the Tool Builder, too, and is described in section

38 Figure 19: The SVNProjectBrowser The "Refresh" button executes the SVNProjectBrowser >>updateall message to update the view, which updates each specification with the #changed: message send to himself. This message informs it dependents to update, which updates the morphs and the nodes. The "SqueakSVN Project Browser is comparable with the "Monticello Browser" and the "Monticello Repository Browser". The browser displays available packages (which are comparable with the projects of SqueakSVN) and the repositories in which they are included. The browser is needed to commit the changes. The repository browser lists the versioned packages of a repository and displays the accessible versions of the package and its version info. It is needed to to load the newest version of a package. SqueakSVN has one single browser for inspecting the projects and accessing the Subversion functionality, where Monticello needs two browsers (for loading and saving packages) The SqueakSVN Commit Dialog The "SqueakSVN Commit Dialog" consists of three specifications. The first is a PluggableTextSpec to enter the log message. The second, a PluggableListSpec, to show all the changes, which should be committed. And a third specification is a PluggableButtonSpec, the "Commit" button. After entering a log message in the text panel and clicking on the "Commit" button, the system checks if a new revision is needed. This is only true, when the project or parts of the project have changed. If this test succeeds, a new revision is created in the repository and committed with the SVNCommitCommand for the selected node. The PluggableButtonSpec displays all changes, which will belong to the new revision of the selected node and its children. 38

39 This dialog pops up when a node in "SqueakSVN Project Browser" or in the "SqueakSVN System Browser" is committed by the context menu. It can be executed for each SVNNodes. If a parent node is committed, the commit is executed on all its children recursively. Afterward a new commit log is created and shown in the number 2 of figure 19. When no new commit log is shown, clicking the "Refresh" button updates the view manually The SqueakSVN Create Project Dialog "The SqueakSVN Create Project Dialog" consists of three PluggableTextSpecs and two PluggableButtonSpecs. Clicking on the button "Create Project", which causes the system to check if the project name is unique, when it is clicked. The repository path and the optionally working copy path, which have to or can be entered in the other two text panels above, have to be valid, too. When this succeeds the SVNCreateProjectCommand is executed to create a new project, which is set to the current project in the SVNEnvironment The SqueakSVN System Browser The "SqueakSVN System Browser" is the standard tool to develop software applications with SqueakSVN. It inherits its behavior from the OBSystemBrowser, which belongs to the Omni Browser framework. The Omni Browser defines and composes new browsers, which are graphical list-oriented tools to navigate and edit an arbitrary domain. It is designed to be flexible and extensible. The OBSystemBrowser is described by a domain model and a metagraph, which specifies how the domain space is navigated through. Morphs display information in arbitrary forms, this information is gathered from a particular path in the metagraph. The user can interact with a morph, which causes the morph to change its state. The state of the GUI is the collection of the states of each morph [17]. The "SqueakSVN System Browser" can be used to navigate and edit Smalltalk source code and source code, which is under version control with SqueakSVN. In contrast to the "SqueakSVN Project Browser", the "SqueakSVN System Browser" uses announcements to update the view for the browser. Announcement are an implementation of the Observer-Pattern, which the commands uses to update the view. The "OB System Browser" was extended for some special behavior. A new feature of the "SqueakSVN System Browser" is the project mode. To realize this feature an additional panel, an OBTextPanel, was added to the System Browser (see number 1 in figure 20). The user can access a context menu, which lists all existing SqueakSVN projects. The available projects are collected by the SVNEnvironment. Selecting a SqueakSVN project activates the project mode, which can also be done by writing the name of a SqueakSVN project in the panel. The system verifies the validation of input, by checking if such a project name exists. The project mode realizes that every future change belongs to the selected project, like adding or modifying a class or a method. This means that an added class is a SVNClass of the selected project and is under version control 39

40 Figure 20: The SVNSystemBrowser automatically. Additionally, the option "No SVNProject selected" was added to the panel, so that the developer can use the SVN System Browser like the standard System Browser. With this feature activated, it informs the panel to send an announcement to the SqueakSVN environment, that the current project has changed. The panel informs the SVNEnvironment that the selected project is the current project and if it has changed. If this is true the SVNEnvironment executes the SVNEnvironment >>currentsvnprojectchanged message and afterward an announcement to the OB- RefreshRequired class which is responsible to update the presentation of the System Browser. The "SqueakSVN System Browser" is also extended to display status icons (see number 2 and 3 in figure 20) for SVNClasses (number 2) and SVNMethods (number 3). There exist status icons for the states unchanged, added, modified and conflicted. A selected node sends the OBSVNStatusIconClassFilter >>icon:fornode: message which executes a SVNStatusRequest on the node. This request is a Subversion function to get the state from the element of the working copy. There exist 14 different states a element can have, but only the four states mentioned above have an own icon. Gernerally no icon is displayed, only when the displayed elements are under version control, because their state can be requested. The SVNEnvironment checks if the displayed elements are part of the current project, and if this test is true, it executes the SVNStatusRequest on an element to get the state of the selected element and adds the correct status icon. When a SqueakSVN element is selected in one of these panels, the context menu "SVN" get some accessible subentries to execute the Subversion functionality commit, update, revert and so on. These menu entries are observed by the corresponding command, which is responsible for the execution. 40

41 The "view..." button (see number 4 in figure 20) has two new menu entries, that are only available when a SVNMethod is selected. The first is the blame view, which displays the source code in an author per line table. The second entry is the diff view, which is only shown, when the system includes the class DiffMorph. It creates a view to display the differences between the working copy and the base revision or between the head revision and the working copy. These new entries depends on the selected method (see number 3 in figure 20) and are build in the OBSVNMultiUserView with the OBSVNCmdMultiView >>execute message of the class. To see the construction of the menu, the source code of the OBSVNCmdMultiView >>execute is displayed in the figure 21. execute viewtype labels asvnmethod svnlabels labels := #(Source Bytecode Decompile PrettyPrint). svnlabels := #(#Blame). asvnmethod := requestor browser svnenvironment findsvnmethodformethod: (target theclass lookupselector: target selector). (Smalltalk hasclassnamed: DiffMorph ) iftrue: [svnlabels := svnlabels, #(#Diff)]. asvnmethod ifnotnil: [labels := labels, svnlabels.]. viewtype := OBChoiceRequest labels: labels. viewtype ifnotnil: [ (svnlabels includes: viewtype) iftrue: [self perform: (#toggle, viewtype, #:) assymbol with: asvnmethod ] iffalse: [self perform: (#toggle, viewtype) assymbol]]., Figure 21: The OBSVNCmdMultiView>>execute message The standard menu is constructed in the third line, where the labels are set. In the next line the "Blame" entry is added to the menu. Afterward the SqueakSVN environment is called to find the SVNMethod for the selected method. The label "Diff" is only added to the context menu when the class DiffMorph is known by the system. The DiffMorph is a part of the UI-Enhancements. Executing an entry exchanges the text panel below, an OBSVNDefinitionPanel, by sending the messages OBSVNDefinitionPanel >>changetotext, OBSVNDefinition- Panel >>changetotable or OBSVNDefinitionPanel >>changetodiff. These messages exchange the standard morphs to the required morphs. To understand the procedure of exchanging the OBSVNDefinitionPanel, the general construction of this panel will help. The "SqueakSVN System Browser" has a rectangle morph for the lower panel. This morph takes an additional rectangle morph and in this second morph there lies the content morph, which displays in the standard view the source code in a TextMorph for 41

42 a selected element. Executing "Blame" or "Diff" invoke the OBSVNDefinitionPanel >>exchangecontentwithmessage. This message removes the content morph from the second rectangle morph. The new morph is selected in the #changeto... and according to the selected view it is defined in three #changeto... messages, which are mentioned above. The blame command exchanges the OBSVNDefinitionPanel to a new morph. This morph shows the blame view in a table with a PluggableMultiColumnListMorph by executing the OBSVNDefinitionPanel >>changetotable message. The morph displays a table, which content it gets from the SVNBlameRequest for a selected method. The blame visualizes a table with four columns: revision number author line number method text/code So each line of the selected method has a line in the blame view with the additional information, in which revision the line has changed last and which author made this change. The diff command exchanges the OBSVNDefinitionPanel to an DiffMorph by executing the OBSVNDefinitionPanel >>changetodiff message. The DiffMorph gets the diff by executing the SVNCatRequest. This request is done for a modified method between the message and the base revision and for an unmodified message between the message and the head revision. The SVNCatRequest gets the content of the method in the repository. The diff is done between this text and the method source code. "Monticello" does not have an own System Browser. This an advantage of SqueakSVN, the direct integration of developing and versioning in the Squeak standrad workflow. "Monticello" receives events when versioned package are changed. This is controlled by the dependencies, which informs the corresponding MCDefinition, that it has changed. SqueakSVN uses the SVNEnvironment for synchronization tasks The SqueakSVN Repository Browser This browser is created with the Omni Browser framework. It is a System Browser, which only displays element of the selected project, which exists in the browsed revision. All the other classes of the system were hide to get a compact view of the project. The browser displays the content of the repository of a browsed revision. It is a read-only browser, so no object in this browser can be changed. 12 Conclusion SqueakSVN is a manifold application, which has a complex GUI. These GUI is oriented to the Presentation Model of MVP. Using this design pattern, allows the user to 42

43 exchange the GUI easily, with only minor changes in the domain logic. The user can design an own GUI, with his desired functionalities and exchange the standard GUI architecture of SqueakSVN easily. Last but not least, the tool support of SqueakSVN is very manifold. Team development and version control functionalities are integrated in the two main browsers, the "SqueakSVN System Browser" and the "SqueakSVN Project Browser". These tools are easy and intuitively to use, and therefore the incorporation in SqueakSVN will only takes a short time. 43

44 Architecture of SqueakSVN: Data Mapping and Object Model Robert Krahn Hasso-Plattner-Institut, Postdam September 14, 2010 Abstract. In the context of the documentation of the version control client SqueakSVN, this paper presents and documents the mapping between behavior defining Squeak classes and methods and the filesystem entities. It is argued that such a mapping is necessary for using the capabilities of Subversion in a Smalltalk development environment like Squeak. In particular the requirements of the mapping are identified, design decisions are discussed, and the object model of SqueakSVN, which implements the mapping, is presented in detail. One advantage when developing with Squeak is its feature to organize source code in fine-grained semantic units like classes and methods. Developers do not have to manage complex source code files but can operate directly on semantic units defined by their programming environment. Subversion, however, operates on files and directories. When integrating a non-file based development environment like Squeak with Subversion this discrepancy has to be resolved by bridging the gap between the two levels of abstraction. SqueakSVN uses a mapping between Squeak s and Subversion s entities to be able to version Smalltalk 1 code. Apart from the static entity mapping, SqueakSVN provides the typical functionality of a version control system, like genrating differences of versions. Instead of implementing the functionality itself, SqueakSVN uses operations provided by Subversion. The decision to use SVN operations for that purpose influences the mapping and represents an additional requirement. This work describes the requirements on the mapping by identifying the subjects of the mapping and the required operations. The implementation of mapping is presented in detail and design decisions are discussed. The first section describes the requirements of the Squeak-to-Subversion mapping. In section 14 different mapping approaches are discussed in detail and design decisions are 1 In the remaining article Smalltalk is used as a short form for the Smalltalk-80 standard [1] 44

45 explained. Section 15 consists of a description of the implementation of one mapping. Data exchange between layers of the mapping is described in section The last section deals with related work and gives a summary of the elaboration. 13 Requirements This section identifies the subjects of the mapping and the required version control operations Source Code Entities in Smalltalk and Squeak Typically programming systems separate program code from program state [20]. The state of a program is typically stored as source code in files which are processed at compile- or runtime to create application structures such as objects. Smalltalk, however, does not differentiate between application structures and source code. Smalltalk uses a simple but very powerful way to describe systems and their behavior: In Smalltalk literally everything is an object [1]. Each object is an instance of a class which describes the state and the behavior of the object. More precisely the behavior of objects is defined by methods which belong to classes. Consequently, those parts which are typically recognized as source code, namely classes and methods, are also objects. In Squeak all objects are stored in an image file [21]. The objects in the image file are in a binary form in which they can be processed from the virtual machine. The programming of applications is performed via reflection through imperative execution of Smalltalk code in the development environment itself. New classes are created by sending the message #subclass:instancevariablenames:classvariablenames: pooldictionaries:category: to an existing class. New methods are added similarly with the message #compile: which is send to classes. Accordingly, there exists no inherent declarative representation of a Squeak program [22]. Such a program is just the result of the evaluation of a sequence of expressions which caused side-effects on an already running system. For a source code management system this means to collect all the system state via reflection, generate description of classes and methods which allow to store them as textual representation in files. The creation of such a representation is part of the responsibility of the mapping. As for Squeak of version 3.9 and newer an additional behavior defining concept was introduced: Traits [23]. Apart from classes and methods Traits can also be used to compose programs written in Squeak so they must be considered when defining the mapping. Classes, methods and traits are specified by several attributes. These are listed below. 45

46 Attributes of Classes For each class in Smalltalk there exists a metaclass (the class of the class). Instead of considering the metaclass as a separate entity, the attributes of the metaclass (class instance variables and class methods) are stored together with the class. The one-to-one association makes this relationship unambiguous. Name. Each class is identified by its name. The name is a simple alphanumeric string. Superclass. The name of the superclass. Category. Classes are organized in categories. Categories themselves are not first class objects Instance variables. Define the state of the instance of a class. An ordered list of variable names (alphanumerical strings). For all variables it is important that their order is considered. Reloading classes with a changed variable order can alter the semantics of programs. When supporting Tweak variables can also have a XML format [24]. This means that that one variable can be an arbitrary string. Class variables. See instance variables. Class instance variables. See instance variables. Pool dictionaries. See instance variables. Trait definitions. Traits can be composed in classes. For restoring those classes it is necessary to store the name of the used traits (alphanumerical string). Additionally methods defined by the trait can be aliased or rejected which is specified in a trait definition. This definition can be stored as a string. Comment. Each class has one comment. The comment consists of a string and a timestamp. Methods. Each class includes a set of class and instance methods. Methods can be identified by their selector which can be converted to a alphanumeric string. All attributes of a method are listed below Attributes of Methods Selector. A selector is the name of the method. A selector alone cannot identify a method uniquely because there can exist more than one method with the same name. For a unique identification also the class (name) of the method is necessary. Source. The source code of the method is a string. Timestamp. Meta informations about the method like the author and the date of modification. Can be represented as a String. 46

47 Category. The name of the method category. It is a string. Class. The name of the method s class. Instance or class method. A flag if the method is a class or instance method Attributes of Traits The representation of traits is similar to classes with the exception that they do not define state and do not inherited from another entity. Name. See class name. Category. See class category. Methods. See class methods Entities of Subversion Subversion is a file and directory based version control system [2]. Subversions allows to annotate files and directories with properties. entities are the storage units of SqueakSVN. Besides that, These three Path of file or directory. A path consists of a path to a parent directory and the name of the file/directory and can be represented as a String. However, there are certain characters which cannot be part of a path string. This is file system dependent. A path uniquely identifies files/directories so that two files/directories cannot share the same path. Content of file. File contents can be represented as strings. Properties. A file/directory can have an arbitrary number of properties. Each property consists of a key and a value which both are strings. The key uniquely identifies a property. Properties are only available for files and directories which belong to a SVN repository or working copy Required Version control operations Besides the pure conversion SqueakSVN should also provide operations which are necessary for a version control system. During the analysis phase following operations were identified: Organization in projects. All versioned classes and methods should belong to exactly one project. Projects contain classes and methods and act as packages (User story 6). Checkout. Existing projects can be loaded from SVN repositories into Squeak images (User story 7). 47

48 Adding elements. The user should be able to determine classes and methods which are then added to a project and are under version control from this moment on. If a user adds a class, all methods are added automatically. If a user adds a method but the class of the method is not yet in a project, the method is directly added to the project. All of this is done explicitly (User stories 1, 2). Removing elements. Entities which should no longer belong to a project are required to be removable from version control (User stories 3, 4). Committing changes. The user should be able to explicitly send his changes to the repository. A commit should be possible not only for whole project but also for classes and methods (User stories 8, 9, 10). Updating. On explicit request a user specified version of project or its classes or methods should be transfered and loaded from the repository into the Squeak image (User stories 11, 12, 13, 18, 19, 20, 25, 26, 27). Reverting. The state of locally modified entities can be reseted to their state of the last update (User stories 23, 24). Resolving conflicts. When loading new versions of project or its classes and methods conflicts can occur. The user must be able to solve the conflicts manually (User stories 8, 9, 10). Blame view. For methods a view can be generated which displays the authors per line (User story 40). Diffing. Two versions of SqueakSVN elements can be compared with each other and a per line diff view can be generated for them (User stories 32, 33, 34, 37, 38). Status and versioning informations. Informations about SqueakSVN elements are available for the user. This includes the current revision of a SqueakSVN element, its commit logs, and if it is unchanged, modified, added or conflicted (User stories 42, 43). Browsing the repository. It should be able to browse versions of the content (projects, classes, and methods) of SVN repositories without loading those entities in the file system working copy (User story 41). 14 Mapping Approaches All of Squeak s objects can be represented as Strings. Classes are defined by their class definition, their comments are just text, the timestamp of the comment can be serialized, methods are defined by their source code, their class, and their timestamp. These string representations can be stored in the filesystem. When creating changesets and fileouts exactly this is done. Serialized representations of classes, methods and 48

49 expressions are gathered and written to one file. All elements can be restored from this file. Existing version control systems for Squeak like Monticello use this technique Mapping to one file Creating fileouts for the classes and method of a SVNProject would also be a possible serialization strategy for SqueakSVN. However, problems appear when using this approach to store the SVNElements into a file. A goal of the project was to reuse as much functionality of Subversion as possible. It is, for instance, desirable to use the SVN diff procedures which are provided by the SVN API to let Subversion generate the differences. If there is only one file it would of course be possible to generate a diff with SVN. The result, however, would only be a string in which it is not possible to distinguish between the classes or methods. From Squeak3.9.1 of 2 March 2008 [ latest update: #7075] on 11 June 2008 at 2:08:50 pm! Object subclass: #Fibonacci instancevariablenames: classvariablenames: pooldictionaries: category: ExampleCategory!!Fibonacci methodsfor: calculating stamp: rkrk 6/11/ :08! fiboof: aninteger aninteger <= 1 iftrue: [1] iffalse: [(self fiboof: aninteger - 2) + (self fiboof: aninteger - 1)].!! Listing 1: A simple fileout of a class named Fibonacci An example should clarify the problem: In listing 1 the contents of a file, which was created with a fileout, are shown. This file was committed to a SVN repository. Afterwards the method #fiboof: was changed: In the line iffalse: [(self fiboof: aninteger - 1) + (self fiboof: aninteger - 2)]. the 1 and 2 were swapped. The new fileout was committed and then a svn diff created. The result of the diff is in Listing 2. Index: Fibonacci.st =================================================================== --- Fibonacci.st (revision 1) +++ Fibonacci.st (revision 2) -10,4 +10,4 aninteger <= 1 iftrue: [1] - iffalse: [(self fiboof: aninteger - 1) + (self fiboof: aninteger - 2)].!! + iffalse: [(self fiboof: aninteger - 2) + (self fiboof: aninteger - 1)].!! Listing 2: SVN diff output of two, slightly different versions of the fileout of Listing 1 49

50 The format which is used for the diff is similar to unix diff command. In the header of the diff svn informations like the filename and revisions of the diff appear. Below the source code is shown. There are three lines before and after (by default) a difference (that is when a line of one file does not equal a line in the other). The occurrence of the diff is indicated by a + or - character in front of the line. Although the output of the diff command can easily be parsed, it becomes obvious that the name of the method does not appear. For getting the name of the method, the following would be necessary: The original Fibonacci.st at revision 1 must be available. This file must be parsed and for accessing the line numbers of classes and methods. These can then be compared with the line numbers of the diff to indentify elements. There are two drawbacks in this approach. On the one hand it is necessary to parse both the diff file and the file the diff is based on and then compare line numbers. This is more complicated than the approaches described below. On the other hand, the mere fact that the original file is needed renders the mapping impractical. The main idea for using SVN is its efficient implementation and the fact that only necessary data is exchanged between repositories and working copies. If complete files have to be loaded and read, this advantage exists no longer. Another requirement for SqueakSVN was to allow "cherry picking" [2] for SVN operations. That means that the scope of those operations can be limited to certain SVNElements. For example it would be possible to execute a diff operation only on a file and not on a whole project. A single file mapping strategy would make complicate cherry picking and would introduce the same overhead mentioned above. This is true not only for the diff operation but for all operations described in section Fine grained control should be allowed for each of them. Therefore it is necessary to look for mappings which simplify the process of storing and restoring informations from the entities within Squeak and which use the advantages of Subversion Mapping to several files in one directory To avoid the complexity of restoring elements by parsing strings and to enable cherrypicking, it is possible to assign a file to each class and method. An example should clarify this kind of mapping. Assume that there is a class named ClassA with an instance method ClassA >>m1, a class ClassB with an class method ClassB class >>m2, and a method ClassC >>m3. Each of the methods and the classes ClassA and ClassB should be added to a project named SimpleProject. Figure 22 shows a serialized representation of this project. The class informations are stored in files with the name of the classes. The methods are also represented as files. The name of the method files are prefixed with the class name to which the method belongs. The source code of methods is stored as file content, method meta data as properties of the file. This mapping would fulfill all requirements: extension methods are possible (there exists no class file for the class but a method file like the file for ClassC >>m3 in the example), cherry-picking is possible because the most fine-grained entity - the method - would be represented by a file, the most fine-grained entity of Subversion. 50

51 Figure 22: Example of simple, flat mapping One could argue that this is not very human-readable mapping. Although it was specific requirement of SqueakSVN to create a human-readable mapping, this would be a "nice-to-have-feature". More important than that is the behavior of the SVN operations. For instance, if an user updates a class in SqueakSVN he assumes that this class and all of its methods are updated. Inherently this feature is not provided with this mapping. Only the class file would be updated. It would be necessary to determine the files of the methods before the update. Although this would not be hard this would be overhead compared with the mapping of section Mapping to directory and file hierarchies Figure 33 shows the example from above with a hierarchal mapping. This mapping uses directories to separate the types of the entites which are serialized. The project has its own directory and each subdirectory represents a class. Extension methods are stored as files with the class and method name in the project directory. Class directories contain a file with the class details (attributes of classes) and two subdirectories which accommodate files for the methods. It is no longer necessary add the class name to those files because this information is implicitly given. This has the advantage that file names do not have to be parsed. On the other hand, this mapping is human-readable and is very similar to the view on a class which is provided by a Smalltalk system browser. Operations like update effect whole directory hierarchies if they are executed recursively. This mapping is used by SqueakSVN with two changes: Class details are not stored in one file but in one file per attribute. On the one hand this reduces the overhead of parsing a classdetails file, on the other hand solving conflicts is simpler because it can be directly determined which attribute is conflicted. The other change affects extension methods: They are not stored in the project directory but in a normal class directory. To differentiate that the class is not under version control there exists another attribute (isversioned) in the class. This simplifies storing and restoring extension methods. 51

52 Figure 23: Hierarchal mapping: resolving naming conflicts 15 Implementation This sections describes the implementation the mapping approach of section This is done by introducing SqueakSVN s object model. The object model consists of the classes: SVNElement and its subclasses SVNProject, SVNClass, SVNMethod. The SVNElements use the SVNLoader for manipulating the system and the classes SVNDirectoryEntry, SVNDirectory, SVNRepositoryDirectory, SVNFile, and SVNRepositoryFile for reading and writing content from/to the filesystem. To put those classes and their functionality into a context, figure 24 provides a rough overview of the architecture of SqueakSVN. In the figure there are the interactions between the different subsystems included: a) User actions. SVNElements are the domain model of SqueakSVN. They provide an interface for manipulation which is accessed from SqueakSVN s tools and SVNCommands. b) Loading/Result of system changes. If state changes appear in SVNElements, their correspondent view has to be informed. SqueakSVN uses the Observer pattern [25] to do this. c) Loading. The SVNLoader is responsible for loading and unloading represented classes and methods in and from the system. This is explained in section

53 d) System state. How attributes of Squeak classes and methods are collected is presented in section e) Restoring/Result of SVN request. file system mapping providing an interface for SVN operations which can be used from SqueakSVN s GUI f) SVN Requests/Storing. defining the filesystem mapping and triggering read/write operations g) Storing. See section h) Restoring. See section i) SVN Requests. j) Restoring/Result of SVN Requests. See section Object Model For managing and collecting the state of classes and methods SqueakSVN uses its own object model. The implementation of this object model is straightforward: The attributes of classes and methods (see section 13.1) are integrated in SVNClass es and SVNMethod s. SVNClass es can be created from existing classes. The method #forexistingclass: in listing 3 takes a Squeak class as parameter and assigns all necessary attributes to SVNClass instance variables. Also class and instance methods of the class are added as SVNMethods to the SVNClass. The method SVNMethod >>forexistingmethods: (listing 4) does the same for SVNMethod s. A compiled method is the parameter from which all necessary attributes are read. The object model additionally provides SVNProject s which are containers for SVNMethod s and SVNClass es. They represent the main entity of version control in SqueakSVN and are similar to Monticello packages [26] and Envy applications [27]. In figure 25 a UML diagramm of the SVNElement class structure is shown. The superclass SVNElement defines an uniform interface and implements functionality which is necessary for all SVNElements, especially to load and remove them SVNLoader SVNMethods and SVNClasses can be loaded into Squeak. This means that Squeak method and classes can be created so that they have the state which is defined by the attributes of the SVNMethods and SVNClasses. SVNElements provide a method #load which delegate the task to modify the system to the SVNLoader. The SVNLoader then starts the process of loading by calling the method SVNLoader >>loadsvnclasses:andsvnmethods: (listing 5). This method determines if it is possible to load the classes and methods by determining the superclasses of the classes to load (#adddependenciesofclasses:) and the classes of the methods (#adddependenciesofmethods:). It is then computed if there are classes necessary 53

54 Figure 24: Overview of synchronization 54

55 forexistingclass: aclass self thename: aclass name asstring; superclassname: aclass superclass name asstring; instancevariables: aclass instvarnames; classvariables: aclass classvarnames; classinstancevariables: aclass class instvarnames; pooldictionaries: aclass pooldictionarynames; comment: aclass comment; category: aclass category; isversioned: true. (aclass methoddict values union: aclass class methoddict values) do: [:each self addsvnmethod: (SVNMethod forexistingmethod: each)]. self establishsvnfilesanddirectories. Listing 3: SVNClass>>forExistingClass: forexistingmethod: acompiledmethod methodreference methodreference := acompiledmethod methodreference. self methodselector: methodreference methodsymbol; nameofclass: methodreference actualclass name; category: methodreference category; source: methodreference source; timestamp: methodreference timestamp. Listing 4: SVNMethod>>forExistingMethod: Figure 25: SVNElements: main entities of SqueakSVN 55

56 for the loading which are not in the system or not in the collection of classes to load. Besides, cycles in the inheritance relationship of classes are discovered. If there are no unknown required classes and no inheritance cycle, the load process begins. loadsvnclasses: asvnclassset andsvnmethods: asvnmethodset self adddependenciesofclasses: asvnclassset; adddependenciesofmethods: asvnmethodset. self unknownrequiredclasses ifnotempty: [ self]. (self hascycle: asvnclassset) iftrue: [ self]. self loadsvnclassessorted: asvnclassset; loadsvnmethodssorted: asvnmethodset. Listing 5: SVNLoader>>loadSVNClasses:andSVNMethods: New classes are created by sending a subclass message to a superclass, so a superclass must be already in the system when loading a class dependent on it. Thus, the classes are sorted so that they can be loaded according to their inheritance relationship. Then the method SVNLoader >>loadsvnclass: (listing 6) is invoked for each class to load. In this method the pool dictionaries are restored if necessary. If the class itself already exists in the system then only its definition (variables) are adapted. Otherwise a new class is created by sending a subclass method to the superclass of the class to load. Afterwards the methods of the class are loaded. Methods which do not appear in the class to load but were versioned before loading are removed. This is necessary, for example, when an old version of the class is loaded which has less methods then the current version. On the other hand, methods which are not versioned before loading are not removed. At the end the #initialize method of the class is invoked which is convention of Smalltalk. loadsvnclass: svnclasstoload svnclasstoload pooldictionaries do: [:ea Smalltalk at: ea assymbol ifabsentput: Dictionary new]. (Smalltalk hasclassnamed: svnclasstoload thename) iftrue: [self reloadexistingclassfrom: svnclasstoload] iffalse: [self loadnewclassfrom: svnclasstoload]. self loadsvnmethodssorted: svnclasstoload versionedmethods; removenonexistingmethodsof: svnclasstoload. svnclasstoload theclass initialize. Listing 6: SVNLoader>>loadSVNClass: Methods which do not belong to a class to load (extension methods) are then loaded into the system by sending a #compile method to the Squeak class of the method. All methods are loaded in an alphabetical order. The SVNLoader is not used when classes or methods are removed from the system (only when it is necessary during loading, see above). Also SVNElements do not provide 56

57 such a functionality. This is not necessary because the SystemChangeNotifier is used when an user modifies the system. This mechanism informs SVNElements when methods or classes are removed so that they can process this information and also remove the deleted element from SVN. The SVNLoader provides the basic functionality of modifying the system. It directly uses Squeak s meta object protocol. A similar but more enhanced functionality is provided by the SystemEditor [28]. The SystemEditor atomically modifies the system so that changes are done completely or not at all. This has the advantage that when an error appears during the load process, the system is not in an possibly inconsistent state. Unfortunately the SystemEditor is unstable and still under development so that it was not possible to use it for SqueakSVN Serialization SqueakSVN uses a SVN filesystem working copy for locally modifying files and directories which were loaded from a SVN repository. These files and directories are used for storing SVNElements as described in section Squeak is based on Smalltalk-80 and thus provides already methods for interacting with the filesystem [1]. The two classes which are most important are FileDirectory and FileStream. FileDirectory provides an interface for accessing, creating and deleting directories as well as creating file streams. It is then possible to read and write files using those file streams via the interface of the FileStream. In the beginning of the development of SqueakSVN, SVNElement s directly accessed files and directory by using instances of FileDirectory and FileStream. With the evolving system, however, the responsibilities of the SVNElement s grew. It is not only necessary to create, read, and write files and directories but to execute SVN operations on them. Additionally, the requirement to load SVNElements directly from the repository without creating local files and directories for them makes it necessary to provide a flexible way of reading files and directories SVNDirectoryEntries The SVNDirectoryEntries (figure 26) were created to provide this flexibility and a unified interface for SVNElements to modify files and directories. Each SVNDirectoryEntry has a name and a basepath which uniquely identifies the object. Futhermore, each SVNDirectoryEntry can add keys and values to a properties dictionary. The items of this dictionary are added as SVN properties when a message #write is sent. The message #read restores SVN properties from the file or directory of the file system. SVNDirectory entries are automatically added (in the sense of a SVN add) to a filesystem working copy. SVNDirectoryEntries also provide an interface to SVN operations which can be executed on files and directories. To fulfill the requirements SqueakSVN must be able to add, update, commit, remove, and revert files and directories. Besides, informations about the state (modfied, conflicted,... ) and commit logs as well as arbitrary 57

58 Figure 26: SVNDirectoryEntry hierarchy informations like the revision or the url of the file or directory must be accessible. In listing 7 the implementation of the update method is shown. It simply executes a SVNUpdateRequest and triggers a #read message. The other SVN commands are implemented in the same way. Each of them executes a SVNRequest. svnupdatetorevision: svnrevision (SVNUpdateRequest target: self updatetorevision: svnrevision berecursive: true) execute. self read. Listing 7: SVNDirectoryEntry >>updatetorevision: shows how Subversion operations are interfaced from SVNDirectoryEntries SVNFile s and SVNDirectories extend SVNDirectoryEntries for providing specific behavior. The #read and #write methods use instances of FileStream and FileDirectory to access and modify files and directories. For example, the SVNDirectory class adds a call to #readdirectoryentries to the #read method. The method is shown in listing 8. The content of the directory identified by SVNDirectory >>path (which is the basepath concatenated with the name) is read 58

59 with FileDirectory. No longer existing files and directories are removed. readdirectoryentries dir dir := FileDirectory on: self path. self subdirectories removeallsuchthat: [:ea (dir directorynames includes: ea thename) not]. (dir directorynames reject: [:ea self shouldbeignored: ea]) collect: [:ea SVNDirectory named: ea basepath: self path] thendo: [:ea ea read. self addsubdirectory: ea]. self files removeallsuchthat: [:ea (directory filenames includes: ea thename) not]. (directory filenames reject: [:ea self shouldbeignored: ea]) collect: [:ea SVNFile named: ea basepath: self path] thendo: [:ea ea read. self addfile: ea]. Listing 8: SVNDirectory>>readDirectoryEntries SVNRepositoryFile s and SVNRepositoryDirectories are used to directly read files and directories from the repository. The two classes provide the same interface as normal SVNDirectoryEntries and can substitute them. They represent an implementation of the strategy pattern [25]. Of course, just read-only operations can be executed on them. Write operations or SVN operations which would modify files or directories are not allowed. Contrary to SVNDirectory >>readdirectoryentries of listing 8 the method #read- DirectoryEntries of SVNRepositoryDirectory uses the SVN list command to collect files and directories (listing 9). readdirectoryentries svnlist svnlist := (SVNListRequest target: self forrevision: self revision) execute. svnlist directorynames collect: [:ea SVNRepositoryDirectory named: ea basepath: self path revision: self revision] thendo: [:ea ea read. self addsubdirectory: ea]. svnlist filenames collect: [:ea SVNRepositoryFile named: ea basepath: self path revision: self revision] thendo: [:ea ea read. self addfile: ea]. Listing 9: SVNRepositoryDirectory>>readDirectoryEntries SVNRepositoryFile uses the SVN cat command instead of file streams to read the content of files. The implementation of SVNRepositoryFile >>readcontent is in 59

60 listing 10. readcontent svncat svncat := (SVNCatRequest target: self forrevision: self revision) execute. self content: svncat contentoftarget. Listing 10: SVNRepositoryFile>>readContent Serializing SVNElements When a SVNElement is created it automatically creates one or more SVNDirectoryEntries in which the attributes of the SVNElements can be stored. The created SVNDirectoryEntry (or if there are more then the highest-ranking entry considering the class structure) is stored in the instance variable svndirectoryentry of the SVNElement. SVNDirectoryEntries provide small and simple interface for SVNElements (see figure 26): in SVNDirectories files and subdirectories can be accessed through methods of the same name, properties are a Smalltalk dictionary, and content of files can be accessed via the methods SVNFile >>content and SVNFile >>content:. If the SVNFile or SVNDirectory should really be written, the method #write can be used and the #read reads the contents of a file or directory of the filesystem and initializes the contents of the directory entries in Squeak appropriately. In the SVNElements themselves three methods are important for serializing: #establishfilesanddirectories, #store, and #restore. See figure 27 for the interface of the SVNElements which is used for serializing. Figure 27: SVNElements: interface for serialization The method #establishfilesanddirectories defines what files or directories exists for a SVNElement. In listing 11 the method #establishsvnfilesanddirectories of SVNClass is shown. This method assigns a SVNDirectory with the name of the 60

61 class to the svndirectoryentry (the svndirectoryentry is accessed va the method #directory for convenience). It then creates two subdirectories for the class and instance methods. After that the method constructs a new file for each class attribute (which are defined in the classdetailsdictionary). The directory entries for SVNProjects and SVNMethods are established similarly. establishsvnfilesanddirectories self directory ifnil: [self directory: (SVNDirectory named: self thename)]. self directory createsubdirectorynamed: self nameforinstancemethoddirectory; createsubdirectorynamed: self nameforclassmethoddirectory. self classdetailsdictionary keysandvaluesdo: [:filename :content self directory createfilenamed: filename withcontent: content]. Listing 11: SVNClass>>establishSvnFilesAndDirectories Once the mapping is established, SVNElements can store their attributes with the method #store. In this method the directory entries are accessed and new content is added to them. The method SVNmethod >>store of listing 12 shows how this is done for SVNMethods. The source code of the method is assigned to the content of the SVNFile of the method (svndirectoryentry of SVNMethods is a file and therefore accessed with the method file). Informations like the class name, category and timestamp are added to the properties of the method. store self file content: self source. self file properties at: self nameforclassproperty put: self nameofclass; at: self nameforcategoryproperty put: self category; at: self namefortimestampproperty put: self timestamp. Listing 12: SVNMethod>>store To create or to read SVNElements from files and directories the method #restore is used. Contrary to #store, #restore triggers the #read of its directory entry to ensure that it has the same state than its counterpart in the filesystem. It then simply accesses the directory entries via their interface and extracts the stored attributes. Listing 13 shows the restoring exemplary for the SVNMethod Synchronization Above was disscussed how the mapping is implemented but not when a synchronization between the SVNElements and the files and directories appears. There are two strategies possible: Wait with the synchronization until a SVN operation should be made or do it whenever the state of a versioned SVNElement is changed. 61

62 restore super restore. self methodselector: self file thename asstring; category: (svnfile properties at: self nameforcategoryproperty); source: self file content; nameofclass: (svnfile properties at: self nameforclassproperty); timestamp: (svnfile properties at: self namefortimestampproperty). Listing 13: SVNMethod>>restore Passive Synchronization. Source code changes are only stored in the file system when needed. For most SVN operations it is necessary that the file system working copy is up to date. Consequently, an implementation of this strategy requires to identify these operations and enhance them in a way that they trigger the serialization mechanism. Unfortunately, this also includes SVN operations like status requests which are used to gather informations for the UI. When implementing this strategy, there are noticeable performance decreases when using the SVNProjectBrowser and the SVNSystemBrowser which causes the UI to freeze regularly. This is due to the relatively slow file systems operations. To not slow down the UI, another strategy should be preferred. Active Synchronization The modification, creation or deletion of SVNElements have the effect to immediately change the file system working copy. Whenever a SVNElement is changed, created or deleted a write operation appears. Actions like creating a class or modifying the source code of a method often involves compiling and thus take some time. The user does not notice the write operation so that this strategy has no impact on the UI responsibility. This strategy allows the file system working copy to act as an additional change set from which source code can be restored in case of a crash. Whenever the method #store is send a #write appears. The example of figure 28 shows what happens when a method is changed. Figure 28: Triggered actions on method change The #restore method similarly triggers a #read every time it is invoked. 62

63 15.3 Mapping Operations SVNElements access the SVN operations directly from the SVNDirectoryEntries and usually only delegate the call to their svndirectoryentry. The SVNElements provide methods like #updatetorevision:, #commitwithmessage:, #status, #info, #commitlogs, #revert, and #resolved. This is due to the fact that those operations are invoked recursively and automatically involves their subdirectories and files which are also the contained SVNElements. SVN operations like #status, however, do not provide the necessary behavior and their behavior must be adapted from SVNElements. 16 Related Work 16.1 Envy Envy, which was formerly known as Orwell, is a configuration management tool for Smalltalk [27]. Envy was integrated in VisualWorks and Visual Age Smalltalk [7]. A particular feature of Envy is the management of source code which is directly stored into a central database. Images can be created for working offline but are usually not used for storing the system. With the central repository it is possible for teams to interact and share their code immediately. The central repository is similar to SqueakSVN which is able to use not only one but several SVN repositories. SqueakSVN, however, does not modify the image concept and commits have to be done explicitly. The main entity of Envy are applications. Applications contain subapplications, classes and methods and can specify other applications as required dependencies. Applications were a role model for SVNProjects which are the main entity of versioning in SqueakSVN an contain classes and methods. SVNProjects do not implement dependencies, though. Applications, classes, and methods in Envy have editions, versions, and releases which control the visibility of the changes and manage version dependencies so that changes in one entity (application, method, class) do not lead to incompatibilities with other entities. In SqueakSVN different versions of SVNElements exist but they are created when committing changes to the repository and not explicitly like in Envy. The storage of Smalltalk entities is not done via the filesystem but with a database. Classes are stored as a textual representation: superclass, variable names, metaclass information, editions and release informations are stored. The database key for identifying classes are application name, class name and timestamp. From methods source code, the name, and meta data is stored. Additionally, the bytecode of the compiled method is put into the database (in a relocatable format by replacing references, constants and method symbols). In this regard SqueakSVN resembles Envy closely. SqueakSVN stores the similar information not in a database but within the filesystem. 63

64 16.2 Monticello Compared with SqueakSVN the object model of Monticello very similar, especially concerning methods and classes. Packages, however, rely on the PackageInfo naming conventions [26]. It is not possible to version classes or methods in arbitrary categories. SqueakSVN introduces SVNProjects which enable versioning of arbeitrary elements. Monticello uses fileouts for mapping classes and methods to the filesystem. This means that it is not possible for (the original) Monticello to transfer only diffs between repositories and the Squeak image. Also cherry-picking is not possible. SqueakSVN uses a fine-grained mapping to files and directories and has no such restrictions DVS DVS is the ancestor of Monticello [29]. It uses an enhanced fileout format for mapping classes and methods to a file. This enhanced format allows to use the CVS diff capabilities but makes it necessary to parse the entire fileout themselves. SqueakSVN stores its elements not in one file but in serveral files and directories which can be read directly. However, there exist no binding between DVS and CVS so that the user has to control CVS manually from the command line or a similar CVS client. SqueakSVN provides a full, C-API-based binding between Squeak and Subversion and extensive tool support inside Squeak, which integrates into the normal tooling. 17 Conclusion This work presents the requirements, mapping approaches, and implementation of a mapping of Squeak source code to entities managed by SVN for the purpose of version control. The subjects of the mapping are identified - namely classes, methods, and traits on the side of Squeak and directories and files for Subversion. It is argued that a hierarchical mapping approach which uses all possibilities of files, directories, and SVN properties is preferred to simpler but less expressive mappings especially with regard to SVN operations. An implementation is presented which realizes the requirements. The implementations enables SqueakSVN to collect the state of a program description within Squeak at distinct points in time. This description is stored in a project which can include representations of classes and methods. This representation is then mapped to files, directories and SVN properties which makes it possible to use Subversion for versioning this program declaration. Furthermore the mapping allows to use Subversion operations from within Squeak and directly on the abstraction layer a Smalltalk programmer is usually confronted with: classes and methods. Interfacing Subversion 64

65 18 Einleitung Es gibt viele Möglichkeiten Subversion in Squeak einzubinden. In diesem Kapitel soll dargelegt werden, weshalb SqueakSVN zur Anbindung von Subversion ein Plugin für Squeaks virtuelle Maschine benutzt. Dazu werden verschiedene Ansätze zur Anbindung mit ihren Vor- und Nachteilen diskutiert. Des Weiteren wird die vom implementierten Interface bereitgestellte Funktionalität aufgezeigt. Ausgewählte Teile der bereitgestellten Funktionalität werden dann in ihrer Implementierung genauer betrachtet. Betreffend der Implementierung des Interfaces wird aufgezeigt, welchen Einfluss die Nutzung der C-API von Subversion auf die Primitive des Plugins hat, also auf die Aufrufe, die das Interface letztlich für Squeak zur Verfügung stellt. Dabei ist zu berücksichtigen, dass die C-API für ihre Verwendung bereits Anforderungen definiert, die sich auf das Plugin auswirken. Außerdem wirken sich die Struktur und die Funktionsweise der C-API direkt auf die Primitive aus. Mit den unterschiedlichen Ansätzen zum Anschluss von Subversion beschäftigt sich die Sektion 4.2, dabei geht es in um direkte Kommunikation mit Subversion- Repositories während es in um die Verwendung von existierenden Clients oder von Subversions Client-Komponenten geht. Die Sektion 4.3 hingegen beschäftigt sich mit der Implementierung des Interfaces. In bis geht es genauer darum, welche Auswirkungen die Anbindung der C-API auf die Primitive des Plugins und die Struktur des Plugins selbst hat zeigt die Auswirkungen dabei exemplarisch. 19 Kommunikation mit Subversion Subversion ist ein zentralisiertes Versionskontrollsystem (VCS). Es kann in zwei Hauptbestandteile zerlegt werden, die Client-Komponente und die Repository-Komponente. Beide Teile eignen sich für eine Anbindung durch eine andere Anwendung. SqueakSVN als Integration von Subversions Versionsverwaltungseigentschaften muss entweder Teil der Client-Komponente werden, diese also anbinden, oder aber die Client-Komponente komplett ersetzen, so dass die Repository-Komponente direkt angebunden werden müsste. In diesem Abschnitt werden beide Varianten gegeneinander abgewogen, mögliche Implementierungen theoretisch diskutiert und aufgezeigt, warum das verwendete Interface Teil der Client-Komponente ist und in Form eines Plugins für Squeaks virtuelle Maschine vor liegt Das Interface als Client-Ersatz Damit ein Client auf ein Subversion-Repository zugreifen kann, muss er mindestens eines der Protokolle beherrschen, die das Repository für Zugriffe bereit stellt. Ein Standard-Repository unterstützt derzeit drei Protokolle, wobei die Verwendbarkeit der Protokolle durch äußere Faktoren beeinflusst wird. Auf die beeinflussenden Faktoren wird bei der Behandlung der einzelnen Protokolle hingewiesen. 65

66 Das erste standardmäßig unterstützte Protokoll ist das file-protokoll. Es steht nur für lokale Repositories zur Verfügung, wobei lokal heißt, das Repository liegt auf einer Festplatte oder einem Netzlaufwerk. Repositories dieser Art sind leicht zu erzeugen, die erste Wahl, falls ein Entwickler ein Repository für eigene Zwecke benötigt, und unter Umständen für einige Teams und Entwickler die einzige verwendbare Art von Subversion-Repositories, da das Verwendete auch das einzige Standardprotokoll ist, welches keine Service-Installation benötigt. Gerade aus dem letzten Grund sollte jeder Subversion-Client diesen Protokoll unterstützen und SqueakSVN sollte da keine Ausnahme sein. Ebenfalls unterstützt wird normalerweise der Zugriff via der WebDav/DeltaV- Erweiterung des Hypertext-Transfer-Protocol (http). Repositories, die dieses Protokoll unterstützen, sind recht weit verbreitet, da für den weltweiten Zugriff auf sie bei dem Repository-Anbieter lediglich der beliebte Apache-Webserver mit den nach installierbaren dav- und dav-svn-modul laufen muss. Ein Client ohne Unterstützung für dieses Protokoll verschenkt einen großen Teil potentieller Nutzer. Das letzte Standardprotokoll ist das svn-protokoll. Dieses Protokoll wurde eigens für Subversion entwickelt und ist um einiges schneller als die WebDAV-Alternative. Nachteilig an diesem Protokoll ist jedoch, dass zwar für Repository-Zugriffe kein Apache benötigt wird, dafür aber der Subversion-Server svnserve. Trotz allem sollte ein Client dazu in der Lage sein über dieses Protokoll zu kommunizieren, wenn er auch oder vor allem in einem Umfeld genutzt werden soll, in dem es auf die Bandbreitenausnutzung ankommt. Aufgrund dessen, dass SqueakSVN auf einen möglichst großen Nutzerkreis abzielt, müssten schließlich alle drei Standardprotokolle implementiert werden, da sich nicht voraussagen lässt in welchem Umfeld SqueakSVN zum Einsatz kommen wird. Jedoch kann ein Client nicht nur aus der Komponente bestehen, die mit dem Repository kommuniziert. Direkter Kontakt mit dem Repository bedeutet, dass sämtliche Versionierungsfunktionalität von Subversions Client-Komponente erneut implementiert werden müsste. Das schließt einfachere Dinge, wie das Registrieren von Änderungen, aber auch Komplexeres mit ein, wie z.b. das gesamte Working-Copy-Management oder das Zusammenmischen von Änderungen. Da SqueakSVN eine Integration von Subversion in Squeak und keine Reimplementierung in Squeak sein soll und bereits die Bereitstellung der einzelnen Protokolle ein erhebliches Maß an Zeit in Anspruch nehmen würde verwendet das Interface von SqueakSVN die Protokolle nicht direkt, sondern bindet Subversions Client-Komponente an. Dies hat zur Folge, dass sowohl die Kommunikation mit Repositories als auch Aufgaben der Working-Copy-Verwaltung nicht von dem Interface erledigt werden müssen Das Interface als Teil der Client-Komponente Die Implementierung der von Subversion unterstützten Protokolle, um wie Monticello direkt auf den Repositories arbeiten zu können, ist eine Alternative. Eine Andere ist es einen bereits existierenden Client mit der eigenen Anwendung zu verdrahten oder aber unter zu Hilfenahme der Subversion-API, bzw. der für einen Client relevanten Teile der API, einen eigenen Client zu schreiben und die Kommunikation mit den Repositories 66

67 über den existierenden Client oder API-Aufrufe im eigenen Client abzuhandeln. Die Vorteile dieses Ansatzes gegenüber der Ersetzungsmethode liegen zum einen in der bereits erwähnten anderen Art der Kommunikation, welche die Implementierung von Protokollen unnötig macht, und zum anderen in der hohen Wiederverwendbarkeit der Funktionalität der anzubindenen Komponente, ob Client oder API, denn diese Komponente stellt bereits alle für die Versionierung nötigen Aufrufe in irgendeiner Form zur Verfügung. Im Nachfolgenden werden einige interessante Varianten für die Anbindung von Subversion näher beschrieben und diskutiert Verwendung des Kommandozeilen-Clients via OSProcess OSProcess ist ein zusätzliches Paket für Squeak. Es besteht aus einer Kollektion von Klassen, welche in Squeak ein plattformunabhängiges Interface für die Benutzung dieses Paket bereit stellen, und einem plattformabhängigen Plugin. OSProcess ermöglicht es Anwendungen, die sich auf dem Einsatzsystem befinden, aus Squeak heraus zu Starten und laufen zu lassen durch das Senden von Nachrichten an die Hauptklasse des Paketes, OSProcess. Das Plugin hat dabei die Aufgabe die von OSProcess empfangenen Kommandos mit Mitteln des Betriebssystems umzusetzen. Der Subversion-Kommandozeilen-Client svn ist die Standardbenutzungsschnittstelle für Subversions Versionskontrollfunktionalität. Die Entwicklung dieses Clients ist Teil der Subversion-Entwicklung selbst und der Client wird immer mit den übrigen Subversion-Anwendungen ausgeliefert. Die Idee bei diesem Ansatz ist es eine Abbildung zwischen Klassen und Methoden auf Dateien und Verzeichnisse zu Implementieren um eine durch Subversion bereits versionierbare dateibasierte Working-Copy zu erhalten und dann mit OSProcess auf dieser Working-Copy gültige Befehle an dem Kommandozeilen-Client von Subversion aufzurufen. Tatsächlich wäre dies relativ einfach umzusetzen. Abbildung 14 zeigt Code, der bei Ausführung eine Datei oder ein Verzeichnis zu einer Working-Copy hinzufügen würde. Dabei wäre apath der Dateisystempfad zu der Datei oder dem Verzeichnis. basicsvnadd: apath OSProcess waitforcommand: svn add, apath Listing 14: Die Methode SVNCommandLineClient>>basicSvnAdd Es scheint, als wäre dieser Ansatz eine verwendbare Lösung, vor allem auch da viele Plattformabhängigkeiten mit OSProcess und dem Client überwunden oder verhindert werden könnten und die Befehlssätze für die Versionierung bereits implementiert wären. SqueakSVN unterstützte diesen Ansatz zu Beginn der Entwicklung parallel zu der Interface-Implementierung als Plugin, hauptsächlich um ein hohes Maß an Plattformunabhängigkeit zu erreichen, und noch heute existiert die Klasse SVNCommandLineClient. Der Ansatz wir jedoch schon länger nicht mehr verfolgt und die Klasse findet nur noch in einigen Tests der Plugin-Funktionalität Verwendung, wofür sie sich durch die schnelle Erweiterbarkeit mit Aufrufen des Kommandozeilen- Client und der Vorhersagbarkeit der Ergebnisse eines solchen Aufrufs auch durchaus 67

68 eignet. Es gibt mehrere Gründe diesen Ansatz ruhen zu lassen. Ein wenn auch nicht entscheidene Grund ist, dass das finale Interface immer an das Können und die Funktionsweise des Kommandozeilen-Client gebunden wäre. Soll heißen, dass das Interface vielleicht nicht jeden möglichen Aufruf des Client zur Verfügung stellen würde, aber mit Sicherheit keinen zu Verfügung stellen könnte, den der Client nicht beherrscht. Ein andere, wichtigerer Grund hingegen ist, dass mit OSProcess kaum Plattformunabhängigkeit erreicht werden kann. OSProcess ist derzeit nur für Unix und Windows erhältlich [30]. Eine tiefer gehende Beschäftigung mit OSProcess offenbart zudem, dass zwar das Unix-Paket auch unter Mac-OS funktioniert, aber die Windows-Variante nicht immer mit der Unix-Variation konform geht, bzw. einige Aufrufe noch nicht implementiert wurden. Darüber hinaus zeigt Windows bei der Ausführung von Anwendungen, welche als Konsolenanwendungen kompiliert wurden, ein eigentümliches Verhalten. Derartige Anwendungen benötigen unter Windows eine offene Konsole, von der aus sie gestartet werden können, und wird eine solche Anwendung nicht von einer Konsole aus gestartet, so öffnet das System eine Neue und hält diese offen bis die Anwendung terminiert ist. Subversions Kommandozeilen-Client ist standardmäßig als Konsolenanwendung kompiliert und da Squeak unter Windows nicht in der Form von der Konsole aus gestartet werden kann, dass für mit OSProcess in Squeak gestartete Instanzen des Kommandozeilen-Clients diese offene Konsole verwendet wird, heißt dies, dass für jede in Squeak gestartete Instanz eine neue Konsole gestartet und nach Abschluss der Operation wieder geschlossen wird. Das allein wäre noch kein Problem, doch im Fall von SqueakSVN wird die Dateisystem-Working-Copy als Cache verwendet und so können auch höhere Raten von Anfragen auftreten, zum Beispiel nach dem Status eines jeden Elements in einem Projekt. Diese Anfragen sind in der Regel von sehr kurzer Dauer und nicht nur, dass eine Art Flackern entsteht, bei einem all zu kurzen Aufruf kann es passieren, dass das System oder aber OSProcess das Handle zu diesem Aufruf verliert, mit der Folge, dass das Squeak-Image blockiert wird, da OSProcess intern auf eine Semaphore wartet, welche die Beendigung des bereits terminierten Aufrufs signalisieren soll. Abschließend lässt sich sagen, dass die Realisierung des SqueakSVN-Subversion- Interfaces durch die Verwendung des Kommandozeilen-Clients via OSProcess die potentielle Funktionalität des Interfaces unnötig einschränken würde, unter bestimmten Umständen für Instabilität des ganzen Images sorgen könnte und auch dem wichtigen Ziel der Plattformunabhängigkeit nicht dienlich wäre. Aus Sicht von SqueakSVN besteht im Endeffekt kein Grund diesen Ansatz weiter zu verfolgen Verwendung von Subversions Python-Bindings Generell wird davon abgeraten existierende Clients als Schnittstelle zwischen Subversion und der eigenen Anwendung zu verwenden [2]. Stattdessen bieten die Subversion- Entwickler eine gut strukturierte API, geschrieben in C, und zusätzliche Bingings für weiter Sprachen wie Python, Ruby oder Java, die es ermöglichen einen Subversion- Client zu schreiben ohne eine Zeile C-Code zu tippen. Unter Berücksichtigung dessen 68

69 bieten sich verschiedene Wege Subversion aus Squeak heraus anzubinden. Ein Weg wäre die Nutzung der Python-Bindungs von Subversion. Diese Option würde sich letztlich aus drei Bestandteilen zusammen setzen. Erstens wieder aus einer Abbildung der Klassen und Methoden, zweitens aus einem in Python geschriebenen Subversion-Client und drittens aus Klassen im Image, die die Abbildung vornehmen und mit dem Python-Client kommunizieren. Eine Abbildung der Klassen und Methoden auf Dateien und Verzeichnisse wäre notwendig, da die Python-Bindings lediglich die C-API zugänglich macht und selbige für die Bereitstellung der Client-Funktionalität eine dateibasierte Working-Copy benötigt. Unter Client-Funktionalität sind in diesem Zusammenhang die dem Client überlassenden Aufgaben der Versionierung zu verstehen, wie das Feststellen von Unterschieden oder das Einmischen von Änderungen aus dem Repository in die Working- Copy. Die Erfordernis eines in Python geschriebenen Subversion-Client ergibt sich aus der Verwendung der Python-Bindings selbst. Die direkte Verwendung der von den Bindings bereit gestellten Aufrufe aus Squeak heraus ist nicht möglich, und so wird ein Mittler zwischen Squeak und den Bindings benötigt, eben jener Python-Client. Dieser Umstand unterscheidet diesen Ansatz nicht von Ansätzen, die andere Sprachen in den Vordergrund stellen, wie etwa Java. Selbst eine auf C basierende Alternative käme aufgrund der Struktur der C-API nicht um diesen Schritt herum, obwohl es mit FFI durchaus möglich ist in Bibliotheken abgelegte und in C geschriebene Methoden aus Squeak heraus aufzurufen. Auf den genauen Umstand wird in eingegangen. Die Klassen im Image als letzte Komponente dieser Interface-Variante haben konsequenter Weise die Aufgaben die Abbildung der Klassen und Methoden vorzunehmen, die dateibasierte Working-Copy mit den unter Versionskontrolle stehenden Elementen des Images synchron zu halten, dem Nutzer die Versionsverwaltungsfunktionalität zugänglich zu machen und mit dem Client zur Umsetzung der Aufgaben der Versionskontrolle zu kommunizieren. Möglichkeiten der Abbildung und Synchronhaltung werden bereits an anderen Stelle diskutiert??. Wie eine umfassende Benutzungsschnittstelle aussehen kann ist in 6.4 dargestellt. Zur Kommunikation mit dem Python- Client könnte wieder OSProcess verwendet werden, jedoch wäre es auch möglich diese durch Sockets zu realisieren. Zu beachten ist, dass sich die Wahl, wie mit dem Client kommuniziert werden soll, direkt auf die Implementierung des Client auswirkt. Wird die OSProcess-Variante gewählt, müsste der Python-Client in Analogie zum Subversion-Kommandozeilen-Client implementiert werden, wobei dann wohl der Einsatz des Kommandozeilen-Client dem eines noch zu schreibenden Python-Client vorzuziehen wäre. Bei der Socket-Alternative würde die Auswahl der aufzurufenden Funktionalität nicht an Hand von beim Start an den Client übergebenen Argumenten stattfinden, vielmehr würde der Client als Service oder Daemon laufen und die an seinem Port eintreffenden Daten interpretieren. Wie eine Kommunikation via Sockets zwischen Python und Squeak umgesetzt werden könnte zeigt das Projekt SqueakFS [31] anschaulich. Bei diesem Ansatz generell positiv zu vermerken ist, dass bei der Ausnutzung des Subversion Möglichen keine unnötigen Einschränkungen durch ein vorgegebenes Set an verwendbaren Aufrufen auftreten. Ein Interface würde sicherlich nur eine relativ kleine 69

70 Untermenge dessen benötigen, was ein Subversion-Client angesichts der verfügbaren API-Aufrufe leisten könnte, diese Aufrufe könnten jedoch in spezialisierterer Form sehr viel nützlicher sein, als die vom Kommandozeilen-Client Angebotenen. Auch ist die Verwendung von Python als Programmiersprache in Hinblick auf die Plattformunabhängigkeit der Lösung oder zumindest des geschriebenen Codes sicherlich eine gute Wahl. Als weniger vorteilhaft erscheint jedoch die Wahl der Programmiersprache, wenn man beachtet, dass der Großteil der Arbeit im Python-Client verrichtet wird. Damit geht nicht nur der Bezug zwischen dem Versioniert, den Klassen und Methoden, und der eigentlichen Versionierung der Objekte gänzlich verloren, es geht auch der Bezug zwischen dem Python-Client als Hauptbestandteil der Lösung und Squeak selbst verloren. Auch die Redundanz der dateibasierten Working-Copy könnte als unnötig angesehen werden. SqueakSVN verwendet selbige bewusst als Cache um im Fall eines nicht gespeicherten Images oder eines Absturzes der virtuellen Maschine dem Nutzer die Möglichkeit zu geben seine Änderungen wieder her zu stellen, auch wenn sich der Nutzer derzeit selbst um diese Wiederherstellung kümmern muss. Bei Ansätzen, die die Subversion API direkt oder mittels Bindings verwenden um die Client-Funktionalität bereit stellen zu können, gibt es ohnehin keine andere Option als die dateibasierten Working-Copy mit zu verwalten, da die API ausschließlich dateibasiert arbeitet. Bei einer Verwendung des bereits erwähnten SqueakFS jedoch bestünde noch eine andere Möglichkeit. So könnten die Meta-Informationen, die Subversion zu Dateien und Verzeichnissen speichern kann, im Image vorgehalten werden und bei Anfragen nach einem versionierten Objekt, bzw. nach dessen Dateisystemrepräsentation, könnten diese dann ergänzend zu der implementierten Abbildung in diese Repräsentation geschrieben werden. Selbiges hätte zur Folge, dass Änderungen an den Meta-Informationen wie eine einfache Statusänderung eines versionierten Objekts mit Sicherheit im Image vorgenommen werden müssten, doch eine redundante zweite Working-Copy würde so entfallen. Diese Variante kann jedoch zur Zeit nicht implementiert werden, da SqueakFS momentan nur lesenden Zugriff auf die Dateisystemrepräsentation des Images ermöglicht und somit keine Änderungen in das Image integriert werden können, wie sie bei einem Checkout oder einem Update auftreten würden. Zudem wird sich die Abhängigkeit von FUSE in absehbarer Zeit nicht auflösen lassen, so dass ein solches Interface auf Unix-Systeme beschränkt wäre Ausnutzung der Subversion C-API Neben den bisher vorgestellten Ansätzen zur Anbindung von Subversion durch Implementierung der Subversion-Protokolle, Verwendung des Kommandozeilen-Client via OSProcess und Verwendung von Subversions Python-Bindings ist noch eine weitere Möglichkeit zu berücksichtigen. Dabei wird die C-API von Subversion mit FFI oder durch ein Plugin für Squeaks virtuelle Maschine (VM-Plugin) direkt verwendet. Die Subversion C-API Mit der C-API von Subversion ist es möglich aus C-Code heraus Funktionalität von Subversion aufzurufen und so mit dem eigenen Programm Aufgaben der Versionierung wahrzunehmen. Für andere Sprachen wie Python, Java 70

71 oder Perl existieren Bindings für diese API, so dass auch Programme dieser Sprachen die API benutzen können. Die API ist in Bibliotheken unterteilt. Eine Bibliothek stellt Aufrufe zur Verfügung, die Aufgaben in der Versionskontrolle übernehmen. Eine solche Aufgabe ist zum Beispiel das Working-Copy-Management oder die Bereitstellung des svn-protokolls. Es gibt jedoch auch Bibliotheken, die nur Hilfsroutinen für andere Bibliotheken bereit stellen. Die Bibliotheken der API werden zudem in drei Layer aufgeteilt, den Client-Layer, den Repository-Layer und den Repository-Access-Layer. Die Bibliotheken mit den Hilfsroutinen werden nicht in einem der Layer eingruppiert. Folge dieser Unterteilung ist, dass alle für einen voll funktionsfähigen Client nötigen Aufrufe im Client-Layer konzentriert sind. Der Repository-Layer fasst hingegen Aufrufe zur Repository-Verwaltung und im Repository-Access-Layer liegen Bibliotheken mit Schwerpunkt auf der Kommunikation zwischen Client und Repository. Die Einbindung der API in ein Programm ist einfach. In den Programmquellen müssen die Header-Dateien der Bibliotheken eingebunden werden, aus denen Ausrufe verwendet werden sollen, anschließend können die Aufrufe verwendet werden. Beim Linken des Programms müssen dann die gewünschten Bibliotheken und die Bibliotheken angegeben werden, von denen sie abhängen. Das Beispiel 15 zeigt die Verwendung von API-Aufrufen im Code am Beispiel von svn_client_add. Der Aufruf bewirkt, dass eine Datei oder ein Verzeichnis zu einer #include "svn_pools.h" #include "svn_client.h" int main (){ char* path; svn_boolean_t recursiveflag; // memory apr_pool_t* pool; // client context svn_client_ctx_t* ctx; path = "workingcopy/fileordirectory"; recursiveflag = FALSE; } // initialisation of the memory management apr_initialize(); // memory allocation pool = svn_pool_create(null); // context creation svn_client_create_context (&ctx, pool); // adds a file or directory to a working copy svn_client_add(path, recursiveflag, ctx, pool); return 0; Listing 15: Verwendung von svn_client_add Working-Copy hinzugefügt wird. Bei der Verwendung der API-Aufrufe muss beachtet 71

72 werden, dass die API die APR-Speicherverwaltung benutzt [32]. Die APR-Speicherverwaltung muss vor ihrer Verwendung initialisiert werden und kann dann benutzt werden um Pools, Speicherblöcke mit impliziter Speicherverwaltung, zu erzeugen. Aufrufe der Subversion-API benötigen neben der APR-Speicherverwaltung zudem meistens einen Client Context. Der Client Context wird vom Anwendungsprogrammierer befüllt und enthält Informationen darüber, welche Funktionen beim Auftreten bestimmter Ereignisse aufgerufen werden sollen. Beispielsweise würde die Zeile ctx->notify_func2=mynotifyfunction eingefügt nach der Zeile recursiveflag = FALSE; im Beispiel 15 dafür sorgen, dass die API für jedes Element, das zu einer Woking-Copy hinzugefügt würde, die Funktion mynotifyfunction aufrufen würde. Welche Callbacks bei welchem API-Aufruf implementiert werden können oder müssen kann der Subversion-Online-Dokumentation [33] entnommen werden. Neben den Aufrufen, die ausschließlich die Callbacks des Client Context verwenden, gibt es noch Aufrufe, bei denen zusätzliche Callbacks als Parameter übergeben werden müssen, auch hierbei sei auf die Online-Dokumentation verwiesen. Allgemein werden von den Aufrufen der API oftmals sehr viele Parameter zur Verfügung gestellt, was es ermöglicht das Verhalten der Aufrufe auf den Einsatzfall hin zu spezialisieren. Unter dieser Eigenschaft leidet aber auch das Code-Verständnis, denn die Semantik von Aufrufen wie svn_client_checkout3 mit zehn oder mehr Parametern nicht mehr sofort ersichtlich ist. Bei einer Verwendung der C-API zu beachten ist neben den Callbacks und der umsichtigen Verwendung der Parameter auch, dass Subversion Dateien und Verzeichnisse versioniert. Im Fall von SqueakSVN heißt das, dass parallel zu der Working-Copy in Squeak eine Working-Copy auf Dateiebene mitverwaltet werden muss. FFI Mit FFI können Funktionen in Squeak verwendet werden, die in anderen Sprachen geschrieben wurden. Voraussetzung dabei ist, dass die Funktionen in "Shared Libraries" gebunden sind. Die "Shared Libraries" wiederum müssen in C geschrieben worden sein. oder mit Sprachen, die bei der Objekterzeugung den C-Konventionen folgen. FFI ist die Abkürzung für Foreign Function Interface. Es ist eine Binärschnittstelle zu Bibliotheken, die nicht Teil von Squeaks virtueller Maschine oder eines Plugins für Squeak sind. Um die Schnittstelle benutzen zu können muss eine Methode in Squeak die in 16 gezeigte Form haben. Der Unterschied zu üblichen Methoden in Squeak ist, add: numberone to: numbertwo < cdecl: long add ( long, long ) module: AddModule > numberone + numbertwo Listing 16: FFI-Beispiel: Addition dass die erste Zeile ausführbaren Codes den eigentlichen FFI-Aufruf enthalten muss. An den FFI-Aufruf kann sich Code anschließen, der im Falle eines Fehlschlagens des Aufrufs ausgeführt werden soll. Schlägt ein Aufruf nicht fehl ist die Rückgabe der Methode die in ein Squeak-Objekt übersetzte Rückgabe des Aufrufs, ansonsten wird sie durch den an den Aufruf anschließenden Code bestimmt. 72

73 Ein FFI-Aufruf muss in Winkelklammern stehen. Das erste Schlüsselwort gibt die Aufrufkonvention an, anschließend folgt der Rückgabe-Typ der gewünschten Funktion, dann der Name der Funktion in Hochkommas und schließlich die Typen der übergebenen Parameter in Rundklammern gefolgt von dem Schlüsselwort module: und dem Namen der Bibliothek, ebenfalls in Hochkommas. Die Aufrufkonvention ist entweder apicall oder cdecl gefolgt von einem Doppelpunkt, sie legt fest in welcher Reihenfolge die Parameter auf den Stack gelegt werden. Zu den Unterschieden zwischen Beiden sei auf [34] verwiesen. Die Aufrufkonvention verursacht eine starke Plattformabhängigkeit von FFI-Lösungen. FFI stellt für die Rückgabe eine Vielzahl an vordefinierten Typen zur Verfügung. Eine Liste der Typen ist ebenfalls auf [34] zu finden. Für die Übergaben gilt, dass sie automatisch in die angegebenen Typen umgewandelt werden, FFI prüft dabei nicht den Sinn der Umwandlung. FFI lässt außerdem die Definition zusätzlicher Typen zu. Prinzipiell funktioniert FFI in der Form, dass bei einem Aufruf die an den Aufruf übergebenen Parameter in die angegebenen Typen umgewandelt und in Abhängigkeit von der Aufrufkonvention auf den Stack gelegt werden. Außerdem wird das Modul detektiert. Anschießend wird dann der Aufruf der Bibliothek ausgeführt und die Rückgabe registriert. Zum Abschluss wird die Rückgabe unter der Annahme sie hat den angegebenen Rückgabe-Typ in ein Squeak-Objekt umgewandelt und als Rückgabe der Methode zur Verfügung gestellt. Schlägt dieses Vorgeben fehl wird der auf den FFI-Aufruf folgende Code ausgeführt, eine Fehlerbehandlung bei FFI ist nicht möglich. VM-Plugin Ein Plugin für Squeaks virtuelle Maschine, ein VM-Plugin, ermöglicht es die virtuelle Maschine von Squeak um neue Funktionalität zu erweitern. Es handelt sich bei einem VM-Plugin um eine neue Bibliothek, die entweder direkt in die virtuelle Maschine gelinkt und verwendet werden kann, oder aber in Form einer "Shared Library" als externes, austauschbares und nachinstallierbares Plugin genutzt wird. Es ist möglich ein VM-Plugin in C zu schreiben, VM-Plugins können aber auch direkt in Squeak geschrieben werden. Wird ein VM-Plugin in Squeak geschrieben kommt dafür Slang zum Einsatz, eine Untermenge der Sprache Smalltalk die sich direkt in C-Code übersetzen lässt. Außerdem ist es möglich in dem VM-Plugin-Code direkt C-Code anzugeben. Die Grundlage für ein VM-Plugin stellt eine Klasse dar, die in der Vererbungshierarchie unterhalb der Klasse InterpreterPlugin angesiedelt ist. Wenn eine solche Klasse als VM-Plugin verwendet werden soll müssen alle ihre Methoden in Slang geschrieben werden. Methoden, die später aus dem Image heraus benutzt werden sollen, müssen zudem mit der Zeile self export: true als zu exportieren markiert werden. Um dann aus einer Klasse ein VM-Plugin zu generieren muss sie zunächst in eine C-Code- Datei umgewandelt werden, dazu stellt die Klasse VMMaker ein Interface bereit. Ist die C-Code-Datei erzeugt kann daraus eine "Shared Library" für ein externes VM-Plugin oder eine einfache Bibliothek zum Linken in den Übersetzungs- und Linkprozess der virtuellen Maschine erzeugt werden. Gegebenenfalls müssen für das Kompilieren und Linken noch Teile der virtuellen Maschine oder andere Plugins in C-Code umgewandelt werden. Mindestens der Übersetzungs- und Linkprozess muss für jede Plattform, auf 73

74 der das VM-Plugin benutzbar sein soll, wiederholt werden. Ein VM-Plugin wird für gewöhnlich noch durch Klassen ergänzt, die die im Plugin implementierte Funktionalität zugänglich machen. Die Vorgehensweise ähnelt der bei FFI. Eine Methode muss die in 17 zu sehende Form haben. Dabei enthält die erste primitiveadd: numberone to: numbertwo < primitive: addnumberoneandnumbertwo module: AddModule > numberone + numbertwo Listing 17: VM-Plugin-Beispiel: Addition Zeile ausführbaren Codes den Aufruf des verwendeten Primitives und alle Folgezeilen enthalten Code, der nur im Fehlerfall ausgeführt wird. Ein Primitiv ist eine Funktion in einem VM-Plugin oder besser eine Methode in der Ausgangsklasse des VM-Plugins. Ein Aufruf eines Primitives ist in Winkelklammern gekapselt und beginnt mit dem Schlüsselwort primitive: gefolgt von dem in Hochkommas gesetzten Namen der Funktion in der C-Code-Datei. Dieser Name unterscheidet sich oft von dem Namen der Methode, da im C-Code beispielsweise keine Doppelpunkte im Namen auftauchen können. An den Funktionsnamen schließt sich das Schlüsselwort module: an. Den Abschluss bildet der wieder in Hochkommas gesetzte Name des VM-Plugins, der bei externen VM-Plugins zugleich der Name der Bibliothek ist. Der Name des VM- Plugins kann sich von dem Klassennamen des VM-Plugins unterscheiden, wenn auf der Klassenseite die Methode modulename überschrieben wurde. Primitive arbeiten direkt mit den Objekten von Squeak, deshalb müssen die Eingaben und die mögliche Ausgabe nicht im Aufruf auf Typen abgebildet werden. Plugin- Entwickler und Aufrufer sollten sich jedoch sowohl bei der Eingabe, als auch bei der Ausgabe über die zu erwartenden Objekte einig sein, illegale Operationen auf einem Objekt aufgrund falscher Annahmen im Plugin können die virtuelle Maschine mit einem Fehler terminieren oder den Squeak-Objekt-Stack korrumpieren. Bei der Funktionsweise eines VM-Plugins fallen im Gegensatz zu FFI wie schon erwähnt die Umwandlungsschritte weg. Das heißt bei dem Aufruf eines Primitives wird das Modul detektiert, die Funktion der Bibliothek ausgeführt, wobei die Funktion direkt auf dem Squeak-Objekt-Stack arbeitet, und abschließend wird das Ergebnis des Primitives als Rückgabe des Aufrufs zur Verfügung gestellt. Schlägt der Aufruf fehl bestimmt der auf den Aufruf folgende Code die Rückgabe. Sowohl eine FFI-Lösung, als auch ein VM-Plugin könnten für die Anbindung der Subversion-C-API genutzt werden. In beiden Fällen kann C-Code aus den Subversion- Bibliotheken aufgerufen werden. Ein sich bei beiden Ansätzen stellendes Problem ist, das die virtuelle Maschine von Squeak nicht wiedereintrittsfähig ist. Das heißt die von Subversion verwendeten Callbacks für den Datenaustausch zwischen Client-Anwendung und Subversion-API müssen bei FFI in einer zusätzlichen Bibliothek implementiert werden, bei dem VM-Plugin muss dies im Plugin-Code geschehen, aus dem später ebenfalls eine Bibliothek wird. Noch problematischer sind Aufrufe der API, die ihre Callbacks mit auch für andere 74

75 Aufrufe relevanten Daten versorgen. Solche API-Aufrufe müssen bei FFI in der zusätzlichen Bibliothek durch Aufrufe gekapselt werden, bei denen erst der API-Aufruf durchgeführt wird und dann die Daten der Callbacks zusammengefügt und in das Image gegeben werden. Bei einem VM-Plugin sind die API-Aufruf in Primitiven integriert. Diese Integration erspart die Implementierung eines weiteren Aufrufs, nicht jedoch das Zusammenfügen der Daten der Callbacks. Weniger problematisch sind hingegen Callbacks, die für ihre korrekte Ausführung Daten aus dem Image benötigen. Die für diese Callbacks nötigen Informationen können vor der Ausführung des API-Aufrufs in Datenstrukturen gespeichert werden, die die Subversion-API zur Verfügung stellt. Ein weiteres Problem für eine FFI-Lösung ist der Umgang der Subversion-API mit Parametern. Für FFI können neue Typen für die Parameter der Eingabe und der Ausgabe angegeben werden, ein Aufruf hat aber immer genau einen Rückgabewert. Bei FFI können Variablen der Eingabe nicht zum Speichern von Teilen des Ergebnisses verwendet werden. Subversion wiederum gibt bei den meisten API-Aufrufen als Ergebnis einen Fehler-Code zurück und speichert die Resultate der Aufrufe in Eingabevariablen. Für die FFI-Lösung hat das zur Folge, dass letztlich alle API-Aufrufe durch noch zu implementierende Aufrufe in der zusätzlichen Bibliothek zu kapseln sind. Die FFI-Lösung würde also auf eine Implementierung eines neuen Subversion-Clients in C hinaus laufen. Das VM-Plugin hat im Gegensatz zur FFI-Lösung keine Probleme mit der Parameterausnutzung von Subversion, was vorrangig daran liegt, dass ohnehin jeder API-Aufruf durch ein Primitiv gekapselt werden muss. Das jeder Aufruf gekapselt werden muss bedeutet, dass das VM-Plugin letztlich eine Client-Implementierung in Slang ist. Das VM-Plugin hat gegenüber der FFI-Lösung zudem den Vorteil, dass das Plugin mit den Primitiven zur Laufzeit eine abstrakte Schnittstelle bietet und die Aufrufkonventionen des Systems nicht von Belang sind. Die Aufgabe von FFI ist es letztlich schon implementierte Bibliotheken ohne großen weiteren Implementierungsaufwand zugänglich zu machen. Die Aufgabe eines VM- Plugins ist es hingegen neue Funktionalität zur Verfügung zu stellen, auch bei größerem zu erwartenden Aufwand. An Hand der Tatsache, dass die Verwendung von FFI den Rahmen der üblichen Nutzung übersteigen würde, der Anschluss neuer Bibliotheken in der Aufgabenbereich eines VM-Plugins zu gehören scheint und der domain-näheren Entwicklung fiel die Wahl bei SqueakSVN auf eine Anbindung der Subversion-C-API Mittels eines VM-Plugins. 20 Interface-Implementierung Das Subversion-Interface von SqueakSVN ermöglicht es Funktionalität der Subversion- Versionskontrolle aus Squeak heraus zu verwenden. Das Interface besteht aus einem Plugin für Squeaks virtuelle Maschine, das Subversions C-API anbindet. In dieser Sektion wird die Implementierung des Interfaces erläutert. Dabei wird darauf eingegangen was bei der Implementierung zu beachten war und welche Funktionalität das VM-Plugin betreit stellt. 75

76 20.1 Verwendete Subversion-API Zur verwendeten Subversion-API ist zu erwähnen, dass für das VM-Plugin die Version 1.4 verwendet wurde. Die Version 1.5 der C-API war zu Beginn der Entwicklung von SqueakSVN nicht ausgereift. Das Interface der 1.4 API wird aber auch in der Version 1.5 zur Verfügung stehen Abhängigkeit der Funktionalität von Dateisystempfaden Die Aufrufe des VM-Plugins arbeiten nicht auf den von SqueakSVN versionierten Klassen und Methoden. Das VM-Plugin bindet den Client-Layer der Subversion-C-API an. In dem Client-Layer der API sind alle Aufrufe gebunden, die benötugt werden um einen neuen Subversion-Client zu schreiben. Da der Client-Layer verwendet wird ist eine dateibasierte Working-Copy notwendig, denn die im Client-Layer gebundenen Aufrufe können nur auf eine solche Working-Copy angewendet werden. Weil das VM-Plugin direkt Aufrufe aus dem Client-Layer verwenden soll, muss zwischen Squeak- Image und API-Aufruf eine Abbildung von Klassen und Methoden auf Dateien und Verzeichnisse stattfinden. Da diese Abbildung leichter im Image vorgenommen werden kann als im VM-Plugin und das VM-Plugin primär einen Mittler zwischen Squeak und Subversion darstellen soll werden dem VM-Plugin nicht die versionieren Klassen und Methoden übergeben, sondern die korrespondierenden Dateisystempfade, auf denen das VM-Plugin dann arbeitet. Viele Aufrufe der C-API von Subversion arbeiten zudem nur auf Pfaden in kanonisierter Form. Die an Subversion übergebenen Pfade müssen als Separator für die einzelnen Pfadbestandteile einen Schrägstrich (/) haben, dürfen nicht auf einem Schrägstrich enden und unter Windows darf bei einer vollen Pfadangabe zwischen den Doppelpunkten der Laufwerksangabe und dem nächsten Pfadbestandteil nur ein Schrägstrich stehen. Dieser Umstand hat zur Erweiterung der Klasse String um die Methode String >>pathforsvn geführt, die einen String in die beschriebene Form dringen kann Die Subversion-Callbacks im SqueakSVN VM-Plugin Vor der Betrachtung der implementierten Funktionalität sei nochmals darauf hingewiesen, das die virtuelle Maschine von Squeak nicht wiedereintrittsfähig ist und aufgrund der von Subversion verwendeten Callbacks für zusätzlichen Datenaustausch bei der Umsetzung einer Funktionalität oftmals neben dem API-Aufruf weitere Aufrufe mit Daten versorgt werden müssen, um den Aufruf zum Erfolg zu führen Umgang mit Übergabeparametern Ein weiteres Problem bei der Anbindung stellen die Parameter der Übergabe dar. Die API von Subversion arbeitet mit C-Datentypen. Das VM-Plugin hingegen bekommt bei einem Aufruf eines Primitives Squeak-Objekte vom Image. Damit Subversion die Parameter verwenden kann müssen diese also nach C konvertiert werden. Für derartige Konvertierungen bietet die Klasse InterpreterPlugin mit dem interpreterproxy bereits 76

77 ein Werkzeug. So liefert beispielsweise die Zeile interpreterproxy intergervalueof: numberobject den C-Wert der Zahl numberobject. Bei Objekten der String-Klasse werden die existierenden Möglichkeiten im VM-Plugin jedoch nicht verwendet, da diese zur Laufzeit Speicher vom Objekt-Stack oder vom C-Runtime-Heap allozieren und so einerseits Speicherlecks entstehen können, andererseits können sie den "Garbage Collector" auslösen. Außerdem könnte so der Speicher anderer Aufrufe korrumpiert werden. Das Entstehen von Speicherlecks könnte durch eine disziplinierte, explizite Speicherverwaltung verhindert werden. Der Speicherkorruption könnte durch umfassende Fehlerbehandlung vorgebeugt werden. Das Auslösen des "Garbage Collectors" kann nicht verhindert werden, was im schlimmsten Fall die virtuelle Maschine mit einem Fehler terminieren könnte. Der Grund hierfür liegt darin, dass nicht nur aus dem VM- Plugin Referenzen auf die C-Strings bestünden, sondern auch aus der C-API sobald ein solcher String aus Übergabeparameter in einem API-Aufruf verwendet würde. Um einen Absturz der virtuellen Maschine zu verhindern werden daher im VM- Plugin für Übergabeparameter nur C-Strings mit einer festen maximalen Länge von 1024 Zeichen benutzt. Die Daten von den eingegebenen String-Objekten werden mit Hilfe der Methode SqueakSVNPlugin >>copyoopstring:tocstring:oflength: kopiert. Dieser Methodenaufruf prüft zunächst, ob die Länge des C-Strings ausreicht um die Daten des String-Objektes aufnehmen zu können. Ist der C-String lang genug werden die Daten kopiert und der C-String nach dem letzten aus dem String-Objekt kopierten Zeichen Null-terminiert, andernfalls wird der Kopiervorgang abgebrochen. Beispiel 18 zeigt den minimal notwendigen Code um den Inhalt eines String-Objektes auf einen C-String zu übertragen. primitive: stringobject... "declare the c string" self var: #cstring declarec: char cstring[1024] ;... "copy the data" self copyoopstring: stringobject tocstring: cstring oflength: Listing 18: Daten von String-Objekten zu C-Strings kopieren 20.5 Umgang mit Ergebnissen der API-Aufrufe Bei den Ergebnissen von Subversion-Aufrufen handelt es sich meistens ausschließlich um solche des Types svn_error_t*, also um Fehlercodes. Die Aufrufe können aber Seiteneffekte auf die übergebenen Variablen haben. Ein Beispiel hierfür ist svn_client_commit3. Bei dem Aufruf ist der erste übergebene Parameter eine Ausgangsvariable und wird während der Ausführung des Aufrufs gesetzt. Soll ein solcher Wert im Image weiter verwendet werden, muss aus dem C-Datentyp ein Squeak-Objekt 77

78 werden. Die Nötigen Umwandlungen können mit dem interpreterproxy bewerkstelligt werden. Das Ergebnis einer solchen Umwandlung ist ein Squeak-Objekt, das in das Image zurückgegeben werden kann. Diese Lösung hat jedoch zwei Nachteile. Nachteil eins ist die Beschränkung auf eine Variable, die für Rückgaben genutzt werden kann. Dieser Nachteil könnte jedoch durch die Verwendung von Arrays revidiert werden. Nachteil zwei ist, dass zwischen der Rückgabe des Ergebnisses an das Image und der Auswertung des Ergebnisses der "Garbage Collector" laufen könnte. Problem dabei ist, dass zu diesem Zeitpunkt keine Referenzen auf das Ergebnis bestehen und es vom "Garbage Collector" gelöscht würde. Die in SqueakSVN implementierte Lösung für dieses Problem gleicht der Vorgehensweise der Subversion-API. Im Detail bedeutet das, dass aus Squeak heraus mehrere Objekte in ein Primitiv gegeben werden. Diese Objekte teilen sich in zwei Gruppen, in Eingabeobjekte und in Ausgabeobjekte. Der API-Aufruf wird unverändert ausgeführt. Im Anschluss an die Ausführung können dann auf die Ausgabeobjekte die Daten von den Parametern kopiert werden, die durch Seiteneffekte in der API gesetzt wurden und normalerweise nicht in der Ausgabe erscheinen würde. Ein Nebeneffekt der Lösung ist, dass die meisten Primitive des SqueakSVN-Interfaces für die direkte Rückgabe die Fehlercodes der von ihnen verwendeten API-Aufrufe benutzen, also lediglich nur noch einen Indikator für Erfolg oder Misserfolg des Aufrufs und keine Objekte, die die Auswirkungen von Seiteneffekten aufzeigen Speicherverwaltung und Client Context Subversion verwendet für API-Aufrufe das Pool-Speicherkonzept der APR [35]. Dabei ist der Pool, der von einem Subversion-Aufruf verwendet werden soll, eine durch die aufrufende Anwendung zu übergebene Variable. Für die Primitive des SqueakSVNPlugins bedeutet das, dass sich selbst einen solchen Pool erzeugen müssen. Außerdem verwenden die meisten Subversion-Aufrufe einen sogenannten Client Context. Der Client Context enthält die Callbacks, die beim Auftreten eines bestimmten vom Aufruf abhängigen Ereignisses während der Ausführung des Aufrufs ausgelöst werden sollen. Außerdem besitzt der Client Context pro Callback einen sogenannten Baton, der mit Informationen gefüllt werden kann. Ein Baton wird bei einem Aufruf des Callbacks, zu dem er gehört, mit an diesen übertragen. Dieses Prinzip wird auch bei der Authentifizierung verwendet Da die meisten Subversion-Aufrufe sowohl einen Speicherpool, als auch einen Client Context benötigen findet sich in den Primitiven des VM-Plugins zumeist die Zeile self initialiselocalpool: (self ccode: &localpool ) AndLocalContext: (self ccode: &localctx ). Dieser Aufruf bewirkt die Initialisierung der für die Ausführung des Primitives nötigen Strukturen. Das betrifft die APR-Speicherverwaltung ebenso wie die Subversion-Bibliothek für Zugriffe auf das Dateisystem. Für eine genauere Dokumentation der nötigen Initialisierungen sei auf das MinimalClientBeispiel [36] verwiesen. Der Aufruf weist außerdem der Variablen localpool einen neuen Speicherpool und der Variablen localctx einen neuen Client Context zu. Die Verwendung von einem globalen Pool und einem globalen Client Context hat sich als nicht praktikabel erwiesen, da auch ein Pool nur begrenzte Kapazitäten besitzt und 78

79 bei einem vollen Pool die Subversion-API interne Aufrufe startet, die Squeaks virtuelle Maschine beenden. Die maximal mögliche Größe eines Pools beträgt 8 KB [37]. Dadurch, dass für jedes Primitiv ein lokaler Pool initialisiert wird, muss jedes Primitiv den lokalen Pool explizit wieder zerstören, wenn der Pool nicht mehr benötigt wird. Die Zerstörung wird mit der Zeile self freelocalpool: (self ccode: &localpool ) veranlasst. Bei einem Aufruf der Methode SqueakSVNPlugin >>freelocalpool: wird dabei direkt die Subversion-Funktion svn_pool_destroy aufgerufen. Abgesehen von den Zeilen für die Erzeugung und Zerstörung eines lokalen Pools enthalten Primitive gewöhnlich noch die Zeile self authenticatecontext: localctx InPool: localpool. Dieser Aufruf setzt die im Fall des VM-Plugin zu informierenden Callbacks, falls ein Repository Authentifizierung anfordern sollte. Was genau in diesem Fall passiert ist in "Authentitifizierter Zugriff in der Beispielbetrachtung" beschrieben Funktionalität des VM-Plugins Mit dem VM-Plugin ist es möglich auf Subversion-Repositories ein Checkout zu veranlassen, ein Update zu machen oder aber Änderungen in einem Commit zu einem Repository zu übertragen. Außerdem ermöglicht das VM-Plugin das Hinzufügen und Entfernen von Dateien oder Verzeichnissen in einer Working-Copy. Das Umbenennen einer Datei oder eines Verzeichnissen wird genauso unterstützt, wie das Hinzufügen von SVN-Properties und das Auslesen von SVN-Properties, Datei-Status oder Commit- Logs. Darüber hinaus werden Schnittstellen für das Auslesen von Informationen einer Working-Copy, der Verzeichnisstruktur eins Repository oder des Inhaltes einer Datei im Repository angeboten. Das VM-Plugin unterstützt auch die bei SqueakSVN verwendete Abbildung von Klassen und Methoden auf Dateien und Verzeichnisse, indem das VM-Plugin Methoden zum Umwandeln von Dateisystempfaden bereitstellt. Vom VM-Plugin werden außerdem die Möglichkeiten angeboten zu Prüfen, ob eine URL auf ein unterstütztes Repository zeigt oder ob ein Repository Authentifizierung verlangt. Das VM-Plugin ist dazu in der Lage die Geschichte von Dateien Zeilenweise wiederzugeben und die Änderungen zwischen zwei Versionen zusammenzufassen. Das VM-Plugin kann zudem benutzt werden, um an einem Repository die Existenz eines SqueakSVN-Projektes zu prüfen oder ein neues Projekt am Repository anzulegen. Es wird von dem VM-Plugin auch eine Möglichkeit der Authentifizierung angeboten. Zusätzlich können mit dem VM-Plugin alle lokalen Änderungen in einem beliebigen Teil einer Working-Copy aufgehoben werden. Auch ein Konflikt kann als aufgelöst markiert oder eine durch nicht abgeschlossene Operationen korrumpierte Working-Copy wieder verwendbar gemacht werden. Im Folgenden sollen einige Teilaspekte im Hinblick auf ihre Implementierung exemplarisch beleuchtet werden. 79

80 Checkout in der Beispielbetrachtung Ein Checkout ist das Anlegen einer Working-Copy von einem Repository. Dieser Schritt stellt die Grundlage der Versionierung mit Subversion dar. Das SqueakSVN-Interface stellt für ein Checkout zwei Primitive zur Verfügung. Das erste Primitiv ist svncheckoutheadrevisionfromto, die Slang-Methode ist SqueakSVNPlugin >>svncheckoutheadrevisionfrom:to:, wobei SqueakSVNPlugin die Klasse des VM-Plugins ist. Bei der Benutzung dieses Primitives müssen zwei Parameter übergeben werden, wobei der erste eine URL zu einem Repository sein muss und der zweite ein lokaler Pfad. Der lokale Pfad muss dabei auf das Verzeichnis zeigen, in dem die Working-Copy angelegt werden soll. Bei einem Aufruf dieses Primitives wird eine Working-Copy mit der im Repository aktuellen Version angelegt. Dieses Primitiv passt sich in die oben diskutierten Grundlagen und Problemstellungen ein, in dem sowohl die Speicherverwaltung wie in "Speicherverwaltung und Client Context" beschrieben gehandhabt wird, als auch Fehlercodes als Ergebnisse des Primitives an das Image geleitet werden. Das Primitiv hat aber keine zusätzlichen Ausgabeobjekte. Die Eingabeobjekte werden als Strings wie in "Umgang mit Übergabeparametern" beschrieben verwendet. Das zweite für ein Checkout zur Verfügung stehende Primitiv ist svncheckoutrevisionbynumberfromto. Die Slang Methode hier ist SqueakSVNPlugin >>svncheckoutrevisionbynumber:from:to:. Dieses Primitiv unterscheidet sich von svncheckoutheadrevisionfromto nur dadurch, dass zusätzlich eine Revisionsnummer übergeben werden muss und nicht die aktuelle Version des Repository an die Working-Copy übertragen wird, sondern die durch die übergeben Nummer spezifizierte Version. Von beiden Aufrufen wird intern die API-Methode svn_client_checkout2 verwenden. Derzeit wird von SqueakSVN bei dem Checkout eines Projektes das Primitiv svncheckoutheadrevisionfromto verwendet. Eine Zusammenführung beider Aufrufe wäre jedoch sinnvoll Update in der Beispielbetrachtung Bei einem Update wird eine existierende Working-Copy aktualisiert oder aber eine frühere Version geladen. Das VM-Plugin stellt für ein Update das Primitiv svnupdatetargetstorevisionkindrevisionnumberberecursive zur Verfügung. Die zugehörige Methode ist SqueakSVNPlugin >> svnupdatetargets:torevisionkind:revisionnumber:berecursive:. Diese Primitiv passt sich genauso in die Problemlage ein wie schon svncheckoutheadrevisionfromto. Das Primitiv kann als Beispiel gesehen werden, wie die Checkout-Primitive zusammengeführt werden. Das Primitiv erwartet als ersten Parameter ein Array-Objekt, das Pfade in kanonisierter Form zu den Dateien und Verzeichnissen beinhaltet. Jeder übergebene Pfad wird dabei einem Update unterzogen. Die Revision, zu der das Update durchgeführt werden soll, wird aus dem zweiten und dritten übergebenen Argument bestimmt. Parameter zwei ist die als Zahl kodierte Art der Zielrevision. Art heißt zum Beispiel 80

81 Head-Revision. Parameter drei ist anzugeben, wenn die Art ein Update zu einer bestimmten Versionsnummer erzwingt. Der letzte Parameter gibt an, ob in Verzeichnissen alle Unterverzeichnisse und Dateien im Update eingeschlossen werden sollen. Derzeit wird das Primitiv von SqueakSVN nur rekursiv verwendet, was ein Update des gesamten unter einem Verzeichnis liegenden Baumes zur Folge hätte. Verwendet für die Umsetzung des Updates wird svn_client_update Authentitifizierter Zugriff in der Beispielbetrachtung Da der Zugriff auf ein Repository durchaus eingeschränkt werden kann ist es notwendig derartige Funktionalität bereit zu stellen. Die unterstützte Authentifizierung beschränkt sich auf Benutzername und Passwort. Sie wird durch je eine globale Variable für Benutzername und Passwort unterstützt und durch einen "Client-Context" besonderer Art erst ermöglicht. Die globalen Variablen lassen sich durch das Primitiv authenticatewithnameandpassword setzen. Dieses Primitiv kopiert lediglich zwei String-Objekte auf die beiden globalen C-Strings und benötigt keine Speicherverwaltung oder ähnliches. Verwendet wird aber das in "Umgang mit Übergabeparametern" vorgestellte Verfahren zum Kopieren eines Strings. Die eigentliche Arbeit der Authentifizierung ist in SqueakSVNPlugin >>authenticatecontext:inpool: zu finden. Die Methode findet sich in Beispiel 19. Die Methode wird von jedem Primitiv aufgerufen, das potentiell auf ein Repository zugreifen kann. Die Authentifizierung wird in Subversion so genannten Providern überlassen. Es gibt verschiedene Arten von Providern. Die Beiden Arten, die in SqueakSVN verwendet werden, sind zum einen die Prompt-Provider und zum anderen die Provider, die auf der Subversion- Konfiguration arbeiten. Die Prompt-Provider stellen eine Schnittstelle zwischen Authentifizierungssystem und Anwendung dar. Bei der Erzeugung eines Prompt-Providers muss ein Callback angegeben werden, den der Provider verwendet um Nutzer-Daten zu erhalten und das Authentifizierungssystem weiterzuleiten. Ein Beispiel für ein Callback wäre pwdcallbackforcredentialemptybatonrealmusernamemaysaveindicatorandpool des Simple-Prompt-Provider aus dem Beispiel. Die andere Art relevanter Provider sind die, die direkt auf der Subversion- Konfiguration arbeiten. Subversion bietet das Speichern von Benutzername und Passwort zu einem Repository an, diese Art von Providern wird dann in Client-Anwendungen benutzt um die Daten wieder für die Authentifizierung verwenden zu können. Diese Provider erhalten ihre Daten direkt vom System, Callbacks sind hier nicht abzugeben. Sind, wie exemplarisch in Beispiel 19 zu sehen, die gewünschten Provider angegeben muss nun noch mit svn_auth_open ein partielles Authentifizierungssystem geöffnet und in einem Client Context verfügbar gemacht werden. Künftig wird bei einem API- Aufruf, der diesen Client Context verwendet, im Falle angeforderter Authentifizierung mit diesen Providern versucht Zugriff zu erhalten. Zugriff zu erhalten wird mit den Providern in der Reihenfolge versucht, in der sie in dem Array der Provider vorkommen. 81

82 authenticatecontext: localctx InPool: localpool provider providers self var: #localctx type: svn_client_ctx_t ; var: #localpool type: apr_pool_t ; var: #provider declarec: svn_auth_provider_object_t provider ; var: #providers declarec: apr_array_header_t providers. self writetexttooutputfile: #authenticatecontext:inpool: Entered. providers := self ccode: apr_array_make (localpool, 4, sizeof (svn_auth_provider_object_t )). "provider for saved password" self ccode: svn_auth_get_simple_provider (&provider, localpool). self ccode: APR_ARRAY_PUSH (providers, svn_auth_provider_object_t ) = provider. "provider for saved username" self ccode: svn_auth_get_username_provider (&provider, localpool). self ccode: APR_ARRAY_PUSH (providers, svn_auth_provider_object_t ) = provider. "password prompt provider" self ccode: svn_auth_get_simple_prompt_provider (&provider, pwdcallbackforcredentialemptybatonrealmusernamemaysaveindicatorandpool, NULL, 0, localpool ). self ccode: APR_ARRAY_PUSH (providers, svn_auth_provider_object_t ) = provider. "username prompt provider" self ccode: svn_auth_get_username_prompt_provider (&provider, usrcallbackforcredentialemptybatonrealmmaysaveindicatorandpool, NULL, 0, localpool ). self ccode: APR_ARRAY_PUSH (providers, svn_auth_provider_object_t ) = provider. self ccode: svn_auth_open (&(localctx) >auth_baton, providers, localpool). self writetexttooutputfile: #authenticatecontext:inpool: Exit. Listing 19: Die Methode SqueakSVNPlugin>>authenticateContext:InPool: 82

83 Repository-Prüfung in der Beispielbetrachtung Mit dieser Funktionalität ist es möglich ab zu prüfen, ob eine URL auf ein unterstütztes Repository zeigt. Unterstützt werden bei Repositories die Protokolle http, file und svn. Über die globale Subversion-Konfigurationsdatei lässt sich zudem auch svn+ssh ermöglichen. Die Repository-Prüfung bietet zudem die Möglichkeit zu prüfen, ob ein Repository Authentifizierung erfordert. Vom VM-Plugin werden zwei Primitive für die Prüfungen bereit gestellt. Das Primitiv svnexistsrepositoryonurl erlaubt die Prüfung auf Existenz und das Primitiv svnrequireauthenticationatrepositoryonurl erlaubt die Prüfung auf Benötigung von Authentifizierung. Beide Primitive rufen intern die Methode SqueakSVNPlugin >>repositoryaturl:exists:andneedsauthentication: auf. Subversion stellt für diese Prüfungen keine eigenen Aufrufe bereit. Um diese Prüfungen dennoch durchführen zu können wurde um den API-Aufruf svn_client_uuid_from_url mit einem Client Context, der von dem sonst verwendeten Client Context abweicht, Code geschrieben, der es ermöglicht die während des Aufrufs aufgetretenen Fehler zu interpretieren. Es gibt nur drei mögliche Endstadien des Aufrufs. Variante eins ist, das der Aufruf glückt, das kann nur der Fall sein, wenn hinter der angegebenen URL ein ungeschütztes Repository zu finden ist. Variante zwei ist, der Aufruf schlägt fehl, aber ein Callback der Authentifizierung wurde betreten. Das heißt, die angegebene URL zeigt auf ein existierendes Repository, das Authentifizierung erfordert. Variante drei besagt, der Aufruf schlägt fehl und kein Callback wird betreten. Das kann nur sein, wenn die URL nicht auf ein Repository oder aber auf ein nicht unterstütztes Repository zeigt. Die Repository-Prüfungen, insdesondere die Prüfung, ob ein Repository existiert, wird in SqueakSVN genutzt um eine Offline-Verwendbarkeit zu erreichen. Die Prüfungen finden außerdem bei der Erzeugung neuer Projekte statt. 21 Zusammenfassung In diesem Kapitel wurden verschiedene Ansätze vorgestellt, wie Subversion aus Squeak heraus angesprochen werden könnte. Es wurde zudem dargelegt, weshalb das Interface bei SqueakSVN aus einem VM-Plugin besteht. Es wurde dargestellt, in wie weit sich die Implementierung des Plugins für Squeaks virtuelle Maschine durch die Anbindung der C-API verändert und wo diese Veranderungen her rühren. Des Weiteren wurde die Funktionalität des VM-Plugins aufgezeigt und Teile dieser in ihrer Implementierung näher betrachtet. Ein nächster Schritt in der Entwicklung könnte die Abtrennung der Authentifizierung in SqueakSVN von Subversion sein, ähnlich wie es im Subclipse-Projekt getan wurde. Dabei werden die Daten des Nutzers ausschließlich in der Anwendung gehalten und ein Speichern von Nutzername und Passwort durch Subversion verhindert. Das hätte den Vorteil, dass der Nutzer zu jeder Zeit volle Gewalt über seine Daten hätte. Künftige Entwicklungen könnten sich zudem mit der Frage auseinander setzten, wie 83

84 die von Subversion verwendeten Callbacks besser integriert werden können. Ein Ansatz wäre die Verwendung von Semaphoren, wie sie von OSProcess benutzt werden. 84

85 Related Work and Comparison 22 Introduction The main goal of SqueakSVN is the implementation of an integration of Squeak and Subversion to make it possible to use the functionality of Subversion in Squeak comfortably. It is essential to collect some information about what kinds of version control exist before this task can be solved. There are several approaches to manage source code and many systems which implement them in different ways. Beside the main task of source code version control the version control systems have to deal with the requirements of different programming environments. This requirements are mentioned briefly in the next section 23. For the reason that version control is so important, it is necessary to have a look at how other version control systems do that. Specials of that systems are as well collected as weaknesses to provide a good solution and to avoid doing the same mistakes. Furthermore a list of several aspects is created to make it easier to compare the different version control systems. This comparison is purposely focused on Smalltalk-based systems. With regards to SqueakSVN it is more interesting to see how other Smalltalk-based version control systems provide version control. The following chapter summarizes other existing version control systems to range in SqueakSVN. It gives an overview about how some version control systems implement the features code version control and code management. The first section 23 divides the current systems into two groups concerning the architecture. Section 24 collects the comparison aspects and gives a clear explanation what is meant by them. Knowing this vocabulary is necessary for understanding the comparison section. Squeak is a Smalltalk-based environment. Therefore it is interesting to see in the beginning how Smalltalk-based version control systems work. That is the reason why this section starts with the current version control system in Squeak, which is called Monticello, followed by ENVY and StORE, and Subversion as an example for non-smalltalk-based systems. The last version control system is SqueakSVN which is described in section

86 23 Existing Version Control Systems In view of the architecture the crowd of existing version control systems can be divided into two groups. There are centralized systems and distributed systems. This classification is shown in figure Fig.29, which also shows which system is Smalltalkbased. Figure 29: The classification of version control systems Centralized systems are characterized by having only one central repository where all changes are saved in. Every developer has access to that database, provided that he is authenticated. Some more detailed explanations will follow. The systems CVS, Subversion and ENVY are members of this group. While working with distributed tools there is no restriction to save the data only in one repository. It assists offline work in a better way, for example when the repository is currently not available. In this case the code can be still be taken under version control. If that repository is available again the changes can be stored there. The advantage of the flexible storing also has a downside. Using several different repositories for versioning means that they always have to be synchronized. That goes ahead with an overhead because of merging over and over again. Monticello, StORE, BitKeeper, GIT, GNU Arch and Darcs belong to this group. It is mentioned above that version control systems have to deal with different requirements. Concerning version and configuration management as well as current development and team coordination. This chapter considers the way the version control systems and their versioning model are integrated with the development environment. Among others it is also examined whether a support exists which provides the auditing of component version and the control of their evolution. While working concurrently in a team it is sometimes important to create parallel lines of development. These lines are called branches. Version control systems have to offer possibilities to create and manage the branches. 86

87 The systems should be simple usable, and the learning curve should be short. How this different architectures affect the work with the tools and how they implement the already mentioned requirements is described in the related sections 25.1 Monticello, 25.2 ENVY, 25.3 StORE, and 26.1 Subversion. 24 Comparison Aspects Now some necessary terms are introduced and explained. They are important for a better understanding of the next sections. The following aspects originate from a website [38] where they are published as comparison aspects as well. Atomic commit. Version control tools, where the commits are atomic, hold the consistency of the data. When there is a failed repository access the data stays consistent. It can not corrupt the repository. That is an important feature which means either the commit of all changes finish successful or no changes were saved to the repository. If there is no support of this feature a network crash can corrupt the consistency of the files. Binary support. Obviously every version control system provides version control of source code, but some of them also provide version control of for example sound, graphic or video files. The possibility of versioning binary files is meant by binary support. Blame - tracking line-wise file history. If blaming is a part of the feature list of one version control tool a mostly visual possibility is given to have a more detailed file history. It shows how the file was changed. Every developer is line-wise listed with every change he made. Branching support. Sometimes it is absolutely necessary to work on different branches. In projects for example somebody has to do some bug fixing while another one work on the main branch for developing. Maybe a third person wants to test some new components at the same time. Tools that support branching offer the developer group to work in several directions simultaneously. Branching can be supported explicitly and implicitly. Explicit means that the developer can create a new branch manually by typing a special command. Version control systems that does not support this feature restrict the developer team to work only on the trunk line. Change set support. Version control systems have several approaches to save changes. There are systems which save the whole code in the repository whenever a commit takes place. That is a very redundancy approach, because the source code is saved several times. It wastes bandwidth and space on disk both on repository side and on local client side. Other version control systems solve the version aspect in another way. 87

88 It is sufficient to save only the current changes or so called deltas. A change set is a collection of those deltas. If a version control system supports this feature, a repository stores only the changes instead of storing the whole source code time and time again. That saves space on disk and also bandwidth, as just the relative small changes are loaded and saved. It is not necessary to load the whole class in which only one line was changed. While keeping changes as change sets the redundancy will be minimized which leads to a better performance. Cherry picking. The common way to get changes of other developers in the image is to choose the version and to load it. Naturally more than one or two single changes are committed. Sometimes changes are made which should not be loaded. Cherry picking is a feature which makes it possible to collect the requested changes and load only them. If cherry picking is not supported every version has to be loaded completely. Commit message - per-file or per-save. When a commit takes place there are two different ways of giving commit messages. If a commit message is per-file, the user can give each file he commits an extra message. Systems that support per-save commit messages offer only a possibility to give one message for the whole commit. Conflict solving. Conflict solving is the way how the tool deals with conflicts. Some version control systems provide a semi-automatic mechanism for dealing with conflicts. It can be taken to means an automatic merge mechanism of all non-conflicting changes and a per-hand solving of the conflicted ones. Some different possibilities exist to solve the problems. One conflicted version can be chosen while loosing at the same time the changes of all other version or a new version can be created. Diffing. This feature differs in entity-based and file-based version control systems. If it is supported by an entity-based tool the user will always have the chance to compare two arbitrary versions of one entity getting information about what changes exists between the two versions, what class was deleted, which line in which method was added and so on. File-based systems that support diffing make it possible to compare two files. File and directory moves or renames. This feature depends on whether a version control system is entity-based or file-based. Entity-based systems can not support this, therefore this feature is not considered in the related sections. File-based systems can support it. If a file is moved or renamed, the history register the file as a new one. That behavior is not the desired one, as the file history is lost. Systems which offer file and directory move or rename with history support are more comfortable in praxis, because the history of the old file is taken over to the new one after a move or rename takes place. 88

89 File and directory copies. This feature also depends on whether a version control system is entity-based or file-based. Entity-based systems can not support this, therefore this feature is not considered in the related sections. File-based systems can support file and directory copies. It is nearly the same as file and directory moves or renames, but here the copy process with history support is considered. Merging. There are some different merging algorithms. With the help of a 3-way merge algorithm developers are able to relate two conflicted versions with the common ancestry version. That provides more information about the changes of the native version, and makes it easier to decide how to integrate the two conflicted versions. In contrast to the 3-way-merge there is also a 2-way merge algorithm. That is a weaker merge algorithm because the common ancestry version is ignored. A few version control systems even offer an arbitrary n-way merge. Meta data. That type of data contains information about the files which should be saved to the repository. Version control systems differ in the way of storing meta data and the content of them. Repository permissions. Of course, Open Source projects do not need them, but sometimes it is requested to restrict the repository access to a small group of developer. There are several approaches to control the access. The easiest conceivable way is to distribute user names and passwords. Tags. Tags are special types to specify milestones in the development process, while marking versions in a special manner. Tracking uncommitted changes. If a version control system keeps every change in mind, it will be possible to inspect the history of the local copy, although the changes were not saved yet to the repository. It also provides the possibility to revert all current changes made to the working copy. Work only on one part of the repository. This is a second way to save space. Every version control system that supports the work on one directory makes it possible to load only that part of the repository the user is currently working on (or interested in). It is a very important feature for bigger projects, because the content in the repository grows. In version control systems that do not support that feature many information of the repository have to be loaded which perhaps is not needed, although the work restricts only on a small part of the repository. Other comparison aspects. When talking about source code management systems it is important to know the versioned entities. Besides the portability is another important aspect. On which machines does the tool work? Is there a restriction to a few (maybe one) programming languages? What kind of possibilities exists to interact with the tool? Are there several graphic clients? 89

90 25 State of the Art Smalltalk Version Control Systems Having this aspects in mind, the next sections detect the features of a few version control systems to see which advantages and also disadvantages they have. This section starts with current Smalltalk-based version control systems as it is shown in figure Fig.29. It starts with Monticello followed by ENVY and ends with StORE. The following section is about non-smalltalk-based version control systems. After that we come back again to the Smalltalk-based systems and add a new one to this group. In this section 27 the features of SqueakSVN are carried together Monticello Monticello is the current system for packaging and versioning Smalltalk code within the Open Source environment Squeak. The development of this integrated version control system started in At the moment the current stable version is Monticello 1. Currently the development of the successor version Monticello 2 is in progress. Monticello works on every machine, where Squeak works on. Squeak is available for Windows, Mac, many Unix systems, some Linux systems and RiscOS. Of course Monticello can take source code under version control, but there is no binary support. That means there is no way to take for example sound files under version control. The overview about Monticello starts with the representation of the architecture followed by the component model. After that the source code version control is described. At last information is given about how Monticello supports team development and how it deals with conflicts Architecture Monticello is a distributed system. It is not necessary to store the code only in one central database. The code can be versioned in several different kinds of repositories. Using several different repositories for version control implies that they always have to be synchronized. A repository can be a directory on the local machine, that makes it easier to work offline. But the code can also be versioned online per HTTP, FTP and SMTP. Projects can be saved on Squeak-Source [19]. It is a free Open Source repository. Another important kind of repository is the automatically created package cache. It is used to cache any package which is loaded into an image as a ".mcz file". That is a zipped file which contains each definition of every method and every class that the package contains. Additionally this file saves meta data of the version, like ancestry information, time stamp, and author. When loading a version, currently the appendant ancestry information will be also loaded automatically. Monticello needs these information to detect conflicts. It is true that ancestry information are also stored in the repository, but the chance, that a necessary version is not available, is reduced by loading these information into the local system. That is a very good solution when a needed version is not saved in any repository, as it is loaded directly from a file. 90

91 In Monticello there is only a simple authentication. Every developer, who has an authorized pair of user name and password, has full access to the repository. The tool does not support a restricted access to parts of the repository. Monticello is not file- and directory-based, therefore the features file and directory move, renames and copies are not considered here. In Monticello there is no way to work only on one part of the repository, except the project in the repository consists of several Monticello packages. In this case it is possible to work on a part of the project. The choice of the part is restricted on one of the packages the project consists of. A more fine-grained access is not possible. Read the following section "Component Model of Monticello" to see how the source code is organized and read the section "Source Code Version Control with Monticello" for learning how the code is versioned Component Model of Monticello In Squeak Smalltalk source code is organized simply. There are methods and classes. Methods, which belong to the same class can be grouped to protocols, but it is not a charge. That is just a possibility to collect methods that have similar things to do. It is a helpful way for a better overview of all methods. On a higher level classes have to be collected together. This organization is called class categories. Classes, which are appropriate for the same task are put into. Every class must belong to a class category. At last there is one unit, which is used to collect class categories together. The so called package is similar to a project in other version control systems. It is the same for the case that a project in Monticello consists only of one package, but not the same if the project based on several packages. The same prefix has to be taken for every class category which should be collected to bring some class categories together. This is the central unit for the source code version control with Monticello as it is described in the next section Source Code Version Control with Monticello While Monticello does not support binaries, Monticello can only take Smalltalk source code under version control. Currently in Squeak there is no way to add for example sound files to projects and version them with the help of Monticello. Monticello is based on a system of packages, snapshots and versions. Package. A package in Monticello is a container which consists of a set of classes and/or extensions. That is the only unit which is under version control. The package model is based on a naming convention which is called PackageInfo. Before a package can be put into a repository, it has to be built in the local system. Therefore the code has to be in one or more class categories with the same prefix. The package is named after the prefix of the class category. Extensions will be marked by an asterisk at the 91

92 beginning and can only be taken under version control with the restrictive naming convention. Snapshot. A snapshot defines the state of a package at a particular point in time. It is created on demand. Having a look at the content of one package is a possible scenario where it is used for. Those snapshots contain sets of class definitions and method definitions. In the file system they are stored in the standard FileOut format. FileOuts are described in section Snapshots can be indicated by the ".st postfix". Version. There is another important unit which is used for storing Monticello packages in the repository. It is called version and consists not only of the package, which should be taken under version control but for several other information. They contain package information namely which package it belongs to. Also part of the container is a snapshot, that contains the source code. Meta data and dependencies are stored there, too. Meta data, that are stored on that way are for example the developer initials, date and time when the version is checked in, and ancestry information. It may well be that the package which should be stored has some dependent packages that have to be loaded before. Those packages are also listed in a version. In the repository they are saved as zipped files with an ".mcz postfix" and a special id. Monticello tracks each uncommitted change to the classes and methods. The approach of doing this is easy. All changes made to the working copy are automatically written into one special file. That means this changes file is a collection of all changes which the developer has made to the system. While coding some changes maybe somebody wants to see what has changed between two versions. Monticello provides the diffing feature, but there is no blame support. There is no special branching support but basic branching is possible. In Monticello there is no native tags support (only with external tools SqueakSource). If the user wants to commit something, the changes are not collected to change sets. The commit is not an atomic process and the commit message, that the user can enter, is a per-save message. Consequently there will be no extra message given to every change. The entered message is for the complete commit. Monticello supports no cherry picking. It is an all-or-nothing strategy. Either a version is loaded with all changes that are made in this version or it is not loaded. There is no chance to collect some changes and load only this collection Concurrent Development Developing in a team is characterized by the concurrent work on the same base of code. Therefore it is possible that two or more developer make changes to the same component at the same time. If the second version should be published in the repository a conflict could occur. The developer, who wants to commit the second version, gets an out of date message. The development can not be resumed until the latest version is loaded. For an easy integration of the code in the working copy Monticello provides a semi-automatism. Every non-conflicted change can be automatically merged, but the conflicted ones have to be solved manually. The solution consists of two possible 92

93 ways. Either to take the changes of the repository version or to take the working copy version. The first way implies that the current changes of the working copy are lost. The result of the second way is that the repository version is overwritten ENVY There are several implementations of ENVY. Examples are Digitalks Smalltalk/ V, Cincom Systems Visual Works and IBM s Visual Age. Both solutions are commercial products. Visual Works is restricted on Smalltalk code. Visual Age supports additionally Java code and operates on Windows Systems and OS/2. IBM s redbook [39] is a very good reference for developing with Visual Age. In contrast to the first version control system of this comparison Monticello ENVY has a different architecture which is represented at first followed by the component model. The role model of component ownership is a special property of ENVY. After that model is introduced the version control is described. At last this section gives information about the conflict solving which differs from many other version control systems, while using the already mentioned component ownership model Architecture The structure is based on a client-server architecture. On one side there are the developers, who work in their local images, and on the other side there is a central repository which saves all changes. So the changes of one developer can not interfere with the work of another developer. The changes are published to the repository for distributing and the developers can choose whether they load the changes into their image or they integrate their own changes later on. In contrast to Monticello ENVY supports only one kind of repository. It is only one file with an easy structure. The so called ENVY Library keeps both formats source code and byte-compiled code. Another difference to Monticello is that ENVY has a centralized structure. While Monticello makes it possible to save some versions on disk and some other in a ftp repository ENVY keeps the whole code in a central point. So every developer has always access to the same code base. ENVY is not file- and directory-based, but entity-based. Therefore file and directory move, renames and copies are not considered here. While in other version control systems (for example in Monticello, Subversion, and SqueakSVN) every authenticated person has full access to the repository, ENVY follows another approach. There is a role model, where there are several privileges. That offers a more controlled access to the source code. The developers have several roles, which offer different possibilities to work with the components. ENVY differentiates the following roles: Class Owner, Class Developer, Application Manager, Configuration Map Manager, and Library Supervisor. But the existing components have to be explained, before this role model can be introduced. 93

94 Component Model of ENVY The component model of ENVY is based on a system of Applications, Subapplications, Configuration Maps, Prerequites, and of course classes and methods. Applications. Applications in ENVY are comparable with modules or packages in other version control systems. They are usable to collect classes and methods to a bigger unit. Within an ENVY image every method belongs to an application. Methods can not exist without applications. Additionally there is no way to have one method in two applications at the same time. Prerequisites. Prerequisites are used for specifying which other code an application expects to access. They have to be in the image before the application can be loaded. Every application has at least one prerequisite. They do not have to form a circle but they shape a hierarchy. The root is the system defining application kernel. Kernel is the prerequisite of every application directly or indirectly. Every application associates some application classes. Application specific behavior like initialization can be sorted there. Subapplications. Applications can be divided into smaller entities. This subapplications can also have their own subapplications. They are similar to applications, but there is a difference. Subapplications can not have their own prerequisites, they inherit them from their parents. The main usage is the partition of platform specific code, which will be loaded only in special configurations. It makes sense to use them to divide huge applications into smaller units. Configuration Maps. Developers are not restricted to divide applications into smaller units. They also organize applications in bigger units. In this case configuration maps are useful. If there is a similarity between applications and modules or packages configuration maps are comparable to projects or program specifications in other source code version control systems. For huge software projects these maps are very important, because they define everything that is needed. They specify each subapplication, class, class extension, and method that an application consists of. At this level it is also possible to give prerequisites. The so called required maps will be loaded before the associated configuration map is loaded Role Model of the Component Ownership It is briefly mentioned above that there is a component ownership model in ENVY concerning every component. That is not quite correct. Methods have no owner. That is the reason why the first role is not a Method Owner but a "Class Owner". The Class Owner has everything to deal with which is connected with the class he created. He is 94

95 authorized to delete or assign the class ownership to another developer if it is desired. Additionally the Class Owner is responsible for publishing changes. Basically a Class Developer is anybody who touches a class. In the client image everybody can do whatever he wants. But if changes should have influence on the development, the class owner has to endorse them. An Application Manager is similar to the Class Owner, the difference is that he owns an application instead of a class. He has more administrative tasks to do. For example he is responsible for creating new editions of his application and for the version control of it. The last but one is the Configuration Map Manager. He creates and versions the editions of his configuration map. Up to now it is not described what an edition is, but it is explained in the next section source code version control with ENVY. There is another role called Library Supervisor. Mostly this is not very important during the development of own projects. The Library Supervisor is the owner of the system classes Source Code Version Control with ENVY Monticello does not work with a component ownership model or something like that. Now it is interesting to see how this distinction influences the concurrent development especially the conflict management. Entities of versioning In other version control systems the name and the type identifies a component explicitly. In ENVY a third dimension was added - the edition. One component (application, class, etc.) can have several editions, every edition differ from each other through the time stamp. This non-varying date means the date of creation of the edition. Once created it will never change. There are two kinds of editions. On the one hand the open edition, which is used to make changes, and on the other hand the frozen edition (is called version) which is immutable. Versions can not be changed. They are used to freeze the state of the current development. The work flow is easy. In the beginning a new open edition has to be created afterwards changes can be made. Eventually a version should be created and the cycle starts again with creating an open edition. While editions are used for making changes and freeze them there is another unit which concerns the load process. It is called release and is used to mark special versions. Whenever a component should be loaded nobody knows which is the version of the containing components that should be loaded. The solution of that problem is the following: The releases give information about which version has to be taken. Making changes ENVY tracks uncommitted changes, but does not work with change sets. The library stores every difference of the working copy as a new version. That means each change will be directly saved in the repository. ENVY supports line-wise tracking of the file history, but does not provide features like diffing, branching, tagging and cherry picking. If there are any changes which have been published in the repository the developers can inform each other about what they have changed with a per-save message. In ENVY the commit operation is atomic. 95

96 Concurrent Development Team development is also possible in ENVY but there are differences concerning the configuration. In the other version control systems of this comparison every developer, who is authenticated, is allowed to make changes to any desired component. In ENVY there is the already mentioned role model. It implies, that everybody can make changes, but only the owner of the component choose the changes he wants to save. Under the circumstance, that there are two different versions of one component, for example of a class, only the component owner can decide which version should be saved. So only the Class Owner of the involved class decides what to do. On the one hand he can choose all changes of the first version or of the second one, while loosing the changes of the respectively other version. On the other hand he can also write his own version and store it instead of both other versions. It is also possible to merge several versions and save that mixture. In ENVY there is no merge mechanism, but language parsers in ENVY provide good support for the merge process. If there is a conflict the component owner has to solve the problems manually in the same way as it is mentioned above StORE StORE is CinCom s solution for version control of Smalltalk source code. Cincom System provides StORE with a commercial license (Cincom Visual Works). It is only available for the Smalltalk environment Visual Works. The "Source Code Management Guide" [8] is a good reference to read about the software development with Visual Works. StORE is an extension to Visual Works to enable browsing, loading, publishing and integration of shared components. In addition to that it allows offline work. A connection to the repository is only necessary to load or publish code. It works on every system that Visual Works operates on. Visual Works 7 was released in 2002 and runs on Windows, Mac OSX, Solaris some Unix and Linux systems. It is entity-based. That means team projects are organized as collection of components. StORE has a similar structure as Monticello. It is mentioned at first in this section. Before information is given about the version control the component model is introduced. At last it is represented how StORE provides concurrent development and how StORE deals with conflicts Architecture Like Monticello StORE is also a distributed version control system. It supports the possibility to work only on one part of the repository. The public repository uses a central server and a PostgreSQL database. It is not file- and directory-based therefore file and directory move, renames, and copies are not considered here. StORE only provides simple repository permissions. The developers are authenticated by evaluating user name and password. 96

97 Component Model of StORE StORE uses a simple component model which combines the functionality of code development and deployment. The first both components "packages" and "bundles" are used during development and the third component "parcels" is used for deployment. Packages. Packages are the main component type. They are understandable as a simple collection of code definitions. These definitions can be class definitions, method definitions, and namespace definitions. There is a similar restriction like in Monticello. Each code definition is associated with one package. Those packages are similar to Monticello packages. This container helps to organize source code in components together, while grouping classes to single function units. The developer can decide the granularity what a package is. Either he wants to summarize a whole application to one package, or it is also possible to put only one single definition into a package. This flexible model makes it possible to create components of their software at any desired granularity. Similarly to Monticello StORE has the same idea to define prerequites. Prerequisite packages can be automatically loaded by StORE. There is a second way of publishing code in the repository to speed up the communication between client and repository. The normal way is to save the code in source format. Beside that way developers can save their code in binary storage format. That implies packages can be loaded with maximum speed. Bundles. The second component which is used during development is the bundle. Packages make it possible to organize at a lower level of granularity. The task of bundles is to organize at a higher level of granularity. While in Monticello there is no way to group packages to a bigger unit this possibility exists in StORE - the bundles. While working with that unit packages and other bundles can be collected. The main use is to create configurations or project specifications as in ENVY. There the configuration maps exist. Both units can be compared. Every bundle has a specification. It contains a list of the names and the versions of components, which are summarized in this bundle. If it is needed to load components in a special order it can be defined in the specification. Grouping projects into bundles makes it possible to store them as a single unit in the repository. Also at this level prerequisites can be given. This way bundles can have prerequisites, too. Parcels. While packages and bundles are used during development parcels are mainly used when a project is ready for deployment. They can used as a medium for internal project releases, too. The advantages of deploying an application using parcels are minimized or eliminated problems involving conflicts and prerequisites. 97

98 Source Code Version Control with StORE StORE tracks each uncommitted changes to the components. These so called "deltas" or "branches" are collected as change sets. The developer can modify his personal working copy as long as he wants. These modifications do not affect the ancestry version of the working copy version. When a commit takes place only these deltas are stored in the repository. The benefit of that way storing only the changes is the maximized performance. The per-save commit message can be used to inform other developers about what has changed in that version. The commit process is not atomic. So a network crash could be a big problem for keeping the consistency of the data in the repository. StORE provides no tools which offer help if it is favored to see who has changed which line in an arbitrary version. So there is no blame support that could be used for line-wise reading of the file history. The only way to see what has changed is to compare two versions with each other. StORE does not provide cherry picking, but something like tags is offered. The user can work with so called blessing levels to keep an overview about the development process. They make it easier to develop cooperatively in a team. The blessing levels can be understood as annotation to the components. With the help of these additional information the developers can inform each other about the status of the particular component. Some of this annotations are "in development", "published", "integrated", "merged", "tested", and "released" Concurrent Development The developers can concurrently work on the same base of code which can be loaded from the repository into the developer images. There they can code on their own without affecting each other. In contrast to the pessimistic model, in which the developers have to follow a "check-in/check-out" scheme StORE follows an optimistic way. It is called "publish and merge". Following that scheme the developers load the version of the repository and work concurrently in their own image on the same code base. They can publish their changes whenever they want without paying any attention to the changes of other developers. Then a new version is created. It is possible that two versions are published which are assigned to the same ancestry version. In that case a new branch will be automatically applied. This branches can be merged at any time later on. When it comes to merge StORE offers a very helpful merge tool. At first this tool identifies each conflict, if there are any. The changes which are made only in one version are marked as non conflicting. These ones are merged automatically. If there are any conflicts, the tool provides some possibilities to solve. No matter how many different versions are conflicted the tool can solve them. The solution is very easy. If a conflict is covered either one definition of the conflicted versions can be chosen or it is also possible to create a new one while loosing the changes of the conflicted versions. Once every conflict is remedied, a new version is saved to the repository. 98

99 26 Non-Smalltalk-based Version Control Systems This section introduces the only non-smalltalk-based version control system of this comparison. SqueakSVN is a linkage between Squeak and Subversion. Therefore it is important to know which features Subversion offers Subversion Subversion is an open-source version control system which was developed by CollabNet in 2000 [40]. Since the start of development it has always been refined. Today CollabNets version control system is one of the most popular tools and is used by many software companies. Subversion is considered as the successor of CVS by the community. These two systems are similar, but CollabNet gives solutions for a few deficits of CVS. Some contrasts are the different counting of revision numbers, the redundancy data saving and the handling of binary files. There are several implementations of a Subversion server and there is also a command line client. The software works on operating systems like Microsoft Windows, several Unix platforms and Mac OS X. Today there are many graphical clients for example TortoiseSVN and also a web interface. There are actually some integrations in programming environments like Subclipse which is an integration in Eclipse. This section offers information about the architecture of Subversion, followed by how the version control is implemented and it ends with the representation of the concurrent development in connection with conflict solving Architecture The architecture of Subversion is based on a client-server principle where the developers work concurrently in client systems and communicate with the central repository to load and publish changes. It saves the units, which should be put there, in a typically form that is also used in the file system. The information are hierarchically stored in files and directories. Possibly they can be supplemented with meta data. Meta data are stored as properties which can be added to any desired file or directory. Repositories can be created in the local file system for example in a special folder. Beside two implementations of a server can be used. The first one, which is called svnserve, needs less resources and is characterized by a simple administration. The disadvantage is the limited function complexity for instance regarding the authentication. In the version 1.4 of Subversion it is possible to give a restricted access to the repository, but once assigned the access rules are strict and not easy to change. There are two possible ways to control the access. Either everybody who is authenticated has full access or an authentication file is used. The first way implies that everyone who wants to access the data have to authenticate himself. To determine whether a repository access is authenticated or not a file with user name and password is used. Possibly the authentication is supplemented with features of SSH. With the help of the authentication file differentiated rules can be assigned. It is 99

100 not possible to mix both kind of access control. Another disadvantage of svnserve is that the users of different repositories have to make known for each repository. A more complex alternative to the svnserve implementation is an module for the Apache Server. This solution needs more resources but provides a better function complexity than svnserve. For example Apache supports the controlled access to several repositories. That means if there are some developers who have access to many repositories, they have to make known only once. While using this server access rights can be given to every directory level. Additionally Apache can work with SSL. To get more information please have a look at the Subversion manual [2] Version Control with Subversion In contrast to some other version control systems Subversion is not entity-based, but file- and directory-based as it is already mentioned above. Subversion is a system that can be used to manage any desired collections of files and directories, and the uncommitted changes made to them, over time. That is the reason why Subversion is not restricted on source code, but it handles binary files as well. Every change of the repository, which is stored there, gets a new revision number during the commit. Each file of one revision can be identified exactly by this global number. While developing with Subversion it is possible to work only on parts of the repository, for example on one directory. In other version control systems which do not support that feature, the developer has to load the whole project of the repository. No matter if the other directories are needed or not. File and directory moves or renames are history supported as well as file and directory copies. Subversion allows to recover older versions of the data, or to examine the history of how the data changed. It is not restricted to see what has changed on one version, it is also possible to compare two versions per diff command. For a better offline work the number of unnecessary accesses to the repository is minimized. The reason for that is that all files are stored twice in the working copy. One version is the current state of the local machine. The other one is the version of the last synchronization with the repository. The second one serves as reference for the uncommitted changes. So only these differences have to be committed. This change set support implies the reduction of the traffic, as only the necessary changes are stored and loaded by the developer. They can inform each other about the changes, they are made in the particular versions, with a commit message, which can be given per-save. The commit process is atomic. So a network crash can not interfere with the consistency of the data in the repository. In view of committing something a special feature which Subversion offers is cherry picking. With the help of it the file or directory can be specified which should be affected by update or commit process. In Subversion there is a simple branching support. It is an implicit support because no extra commands exists for branching. It is a convention to have a special directory called branches. That means branches are only (cheap) copies in the working copy. Another useful feature is tags, which is offered by the same way as copies in the file system. 100

101 Concurrent Development Working concurrently in several clients together version control systems can provide different solutions of making changes. Subversion supports both an optimistic model as it is mentioned in the StORE section 3.3 of this chapter and a pessimistic one. In Subversion the first one is called Copy-Modify-Merge and the second one is the Lock-Modify-Unlock model. How this solutions work and what the advantages and disadvantages of the particular approach are it is readable in the sections 4.2 and 4.1. As already mentioned several times, while developing in a team conflicts can occur. Conflicted files are specially marked. Those files can not be published until the conflict is solved. There is no mechanism in Subversion which can do that. The developers have to solve them after merging for their own in their working copies. Afterwards the patched files can be published again Other Beside Subversion there are many other non-smalltalk-based version control systems as it is already shown in Fig. 29 on page 86. Most of the other version control systems have a distributed architecture, except for the predecessor of Subversion CVS which is a centralized system. CVS is Open Source and operates on Windows, Mac OS X and Unix. A graphic client is available and also a web interface. In contrast to Subversion CVS has some disadvantages. The main downsides are for example that CVS is slower than Subversion and supports neither atomic commits and cherry picking nor file and directory moves, -copies and -renames. BitKeeper is another example for distributed systems. It is a commercial solution for source code restricted version control which is deployed by BitMover, Inc. [41]. The development of BitKeeper started in Beside functionality for version control it also provides bug tracking support. "BitKeeper is used to develop the Linux kernel, the MySQL database, the Xaraya content management system, and hundreds of commercial products worldwide" [42]. BitKeeper is portable to Windows, Mac OS X and Unix. Beside the command line there are graphic clients and a web interface. Please visit its website for getting more information. Other version control systems with a distributed structure are the relative young solution GIT (developed in 2005) [43], GNU Arch [44] which is used to develop the Open Source Linux operating system Debian, and Darcs [45]. These systems and additional many others are compared with each other on this website [38]. 27 SqueakSVN in Comparison This section summarizes the preceding chapters regarding the comparison aspects. Here there will be given only a short overview about the features of SqueakSVN, because they are always covered. It is well-integrated in the Smalltalk environment Squeak and runs on every system Squeak operates on. From the vantage point of Squeak there is an entity-based version model, because inside Squeak each object is under version control. From the outside Squeak point of view it is more a file-based version model. The reason 101

102 for this difference is a mapping takes place. Squeak components are mapped to the file system. How that mapping works and why this is done that is described in the section 15. File and directory moves and copies are not history supported Architecture In contrast to the in Squeak already existing version control solution Monticello SqueakSVN is based on a client-server model. Squeak developer can work in their private image and publish the changes in the central repository. Differently from Monticello each developer has access to the same base of code. Those repository can be a folder in the local file system or on a remote server. Access to this central database has everybody which can authenticate himself with a correct user name and password. The Subversion repository can take binaries under version control, but it is not provided by SqueakSVN. It is still impossible to version sound files inside Squeak. It is also not possible to create branches and tags with the help of SqueakSVN tool set. The tools and their functionality are discussed either in section 6 and in section Source Code Version Control with SqueakSVN SqueakSVN uses the same component model as Monticello, but the units which are under version control differ from the companion pieces in Monticello. In SqueakSVN there is not only one all-embracing package, but several smaller units. These elements are explained in section Each entity in Squeak can be taken under version control. So it is possible to touch every single unit from a method up to a project isolated. That is the reason why the work on one project can be restricted on parts of it. An update of a class is as possible as a commit of a class without affecting the project which contains it. Uncommitted changes are also tracked as in Subversion. So if a commit takes place, only the changes are saved to the repository. The changes can be selected, which should be committed to the repository. That means simple cherry picking is possible. With each commit, which is an atomic process, the developers can give a per-save commit method for giving information about the changes they made in this version Concurrent Development In SqueakSVN the optimistic model "Copy-Modify-Merge" is also used as in Subversion. It is not necessary to lock components. Changes can be made to each component at discretion. Merging of non-conflicted changes is possible as this happens automatically. If two versions are conflicted the tools of SqueakSVN recognize and indicate it. For this case simple possibilities of conflict solving are provided which means either the current changes of the working copy or the changes of the conflicted version in the repository are taken. In contrast to Monticello SqueakSVN provides both diffing and blaming. 102

103 28 Conclusion The last section presents a direct confrontation of the current source code version control solution in Squeak, named Monticello, and the new solution for version control SqueakSVN. It particularizes the advantages and disadvantages of both systems and why Squeak developers should work with the new system. Monticello and SqueakSVN differ in many aspects. The most important ones are shown in Figure Fig.30. Figure 30: Differences between Monticello and SqueakSVN SqueakSVN provides a more efficient software development and supports the corporate work of huge distributed teams better than the current solution, considerably reducing the effort of coordination. With Monticello it is possible to save the code additionally in a local repository, while the main repository is not available. That supports offline work well while enabling consecutive development with version control, but there is an overhead as the repositories have to be synchronized time and time again. This wasteful effort does not exist in SqueakSVN. There is a central repository which lets the developers concentrate on important things like software development. To assist the daily work the new solution enables a more detailed handling of the software elements. SqueakSVN does not work with a restrictive package model like Monticello does. It is dismissed to provide direct version control of the smaller software elements, while a mapping model is used to map the complex structure to flat data structure. This model works automatically in the background to enable the version control with Subversion. The granularity of source code version control is restricted in Monticello by using the already mentioned package model. Therefore there are several disadvantages. On the one hand only extensions with the naming convention can be considered when versioning. On the other hand it does not matter how many changes are done Monticello always creates a new package. Instead of committing the changes the whole package will be committed. So it is impossible to access classes and methods isolated. While using a higher granularity of versioning and collecting changes to change sets, SqueakSVN enables a more flexible version control. SqueakSVN provides intuitionally usable tools, which are well-integrated in the workflow and which add absolute new functionality to 103

104 Squeak. Tracking line-wise file history, change sets, atomic commits and cherry picking are examples what is possible now. While working with Monticello the developers have to resign all this features. Appendix A - Manual This chapter contains other end user specific topics for the reader for look up purposes. 29 Installation Comment: Currently it is not decided how SqueakSVN will be distributed therefore this section is incomplete and subject to changes Three components are necessary in order to be able to work with SqueakSVN. The first component is the package which contains the whole application for Squeak. The second is the plugin which is necessary to communicate with Subversion and the third one is Subversion itself. These three components have to be downloaded and installed in different ways, especially on different platforms. The application for Squeak is distributed in a Monticello package and can be downloaded from the universal package cache on SqueakSource [19] found in the team development category. It can be installed like any other package from the SqueakMap cache. See section for more information on the universe package cache. The plugin can be created in two ways. The first way is to download the SqueakSVN- Plugins package from the SqueakMap cache and to compile the plugin for them self. This is a complicated procedure and therefore not covered in this document. The easier way is to download the pre build binaries for the different platforms which also include the Subversion binaries. They can be found on this website [...]. It is recommended to use the UI-Enhancements mentioned in section 11. When they are used the UI is altered and diffing looks like shown in figure 8 on page 21. They need to be installed separately and can be found in the universe package cache in the user interface category. 30 Creating repositories In order to work with SqueakSVN a repository is needed. There are local and external repositories possible. Local repositories can only be used in a network and are mostly for personal use. External repositories are usually hosted on external servers and accessible through the Internet by many developers. An own local repository can be created with a tool like the command line client "svnadmin". A more comfortable solution is the "SqueakSVN Create Repository Tool", which is accessible through the world context menu by clicking on "open". This tool creates a local repository in a folder for someone who wants to version his code on a network 104

105 drive or on his own computer. It is enough to enter a name for the repository in the upper field and to push the create button to create the repository folder. Optionally there is the lower text field for a path to the directory where the repository should be generated. If no directory path is specified the repository is created in the folder of the image. After creating the repository the tool displays the path to the repository as an URL in the lower text field of the tool. Figure 31 shows a screenshot of the tool. Figure 31: The SqueakSVN Create Repository Tool External repositories run as services on servers in the Internet or in other networks and use different databases as back ends to save their data. For more details on setting up services the Subversion red book [2] is an advisable source. Users can set up a Subversion service on every server they have access to, or they can look for free or commercial services which offer them. A free service could be Sourceforge, where every accepted project receives an own Subversion repository [46]. CollabNet is a commercial alternative which offers this services and started the development of Subversion itself [40]. Repositories in SqueakSVN have the purpose of being repositories for many projects. This means one repository can contain many projects with different names. That way a team can version many different projects in the same repository and organize their work how they would like. 31 Creating projects Projects for SqueakSVN can be created in the "SqueakSVN Project Browser". A "Create project" button is located in the lower left corner of this browser. If it is clicked the "SqueakSVN Create Project" dialog opens. It is necessary to type in the name of the project, a URL to the repository where the project is or should be versioned and optionally the place where the working copy should be located. If no working copy path is entered, the working copy is created in the current folder of the image and the working copy folder is named after the project. The URL and the working copy path have to be valid or the dialog does not create the project. Finally the new project is created if "create" was hit. Usually when a project is created, either this project exists already in the repository or not, a checkout is done of the repository. A checkout is the creation of the working copy and an update to the head revision. 105

106 There is a interesting management feature usable in SqueakSVN. The URL which is entered when a project is created has to point to a repository but can point additionally to a folder of this repository. The repository can contain a folder structure created with other Subversion tools. This way a repository can have folders for different teams or projects. Such a organization could look like this:.\teama\projects2008\project5.\teama\projects2007\project1.\teamb\trunk\mainproject.\teamb\trunk\framework Any time a project is created SqueakSVN checks if already a project at this particular repository exists. This is determined by the name of the project. This means two projects with the same name cannot exist in the same folder of one repository. If there is no project in the repository it is folder is created there. If it already exists, the working copy is updated with the file and directory structure in the repository folder. Then the state of the project in the repository is loaded into the image. 32 Authentication When SqueakSVN tries to access a repository which needs authentication it first checks if the repository login information is available in Subversion or in SqueakSVN. If no information for this particular repository is available the "SqueakSVN Authentication Request" dialog is opened. The developer has to enter his user name and password. Then the system retries the request to the repository. If this request is successful the login information is kept in the application as long as no other repository which needs authentication is contacted. Only if another repository with authentication is contacted the user has to enter the new log in information. 33 Migrating from Monticello The tool "SVNConvertMCPackageToSqueakSVN" was developed to help developers migrate from Monticello to SqueakSVN. It is accessible from the world open menu. It takes a package name and looks in MCRepositories for versions with this name. Then it converts the specified version and all ancestors into revisions of the specified SqueakSVN project. Appendix B - User Stories References [1] Goldberg, A., Robson, D.: Smalltalk-80: the language and its implementation. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA (1983) [2] Ben Collins-Sussman, Brian W. Fitzpatrick, C.M.P.: Version Control with Subversion: For Subversion 1.4: (Compiled from r2866). TBA (2007) [3] unknown author: FileOut Code Format. (visited 06/29/2008) 106 [4] unknown author: Changesets in Squeak. (visited 06/19/2008) [5] unknown author: Monticello. (visited 06/29/2008) [6] unknown author: SqueakMap. (visited 06/29/2008)

107 107

Freelance. Getting Started

Freelance. Getting Started Freelance Getting Started Freelance Getting Started Version 9.2 SP1 NOTICE The information in this document is subject to change without notice and should not be construed as a commitment by ABB. ABB


Table of contents. User Guide

Table of contents. User Guide Table of contents Welcome to SYNCING.NET... 3 Using SYNCING.NET... 3 System Requirements and Installation... 5 System Requirements... 5 Installation... 5 Registration / License... 8 Updates... 9 Uninstallation...



THE USE OF XING AND LINKEDIN FOR RECRUITMENT IN ENTERPRISES THE USE OF XING AND LINKEDIN FOR RECRUITMENT IN ENTERPRISES 22nd June 2012 Carlo Colicchio Iso Demirkaya Alex Hächler Project 1 / FHNW Master of Science in Business Information Systems Introduction Title:


Heiko Bischoff, Masahiro Eto, Pierre Schaller Thanks to: Matthias Klag, Michael Ruf The information in this document is subject to change without

Heiko Bischoff, Masahiro Eto, Pierre Schaller Thanks to: Matthias Klag, Michael Ruf The information in this document is subject to change without Heiko Bischoff, Masahiro Eto, Pierre Schaller Thanks to: Matthias Klag, Michael Ruf The information in this document is subject to change without notice and does not represent a commitment on the part


Supporting Public Deliberation Through Spatially Enhanced Dialogs

Supporting Public Deliberation Through Spatially Enhanced Dialogs MASTER THESIS Supporting Public Deliberation Through Spatially Enhanced Dialogs Gerald Pape 2nd November 2014 Westfälische Wilhelms-Universität Münster Institute for Geoinformatics First Supervisor: Second


User Guide / Bedienungsanleitung. KVM series3-client Client Software for Keyboard/Video/Mouse Switch

User Guide / Bedienungsanleitung. KVM series3-client Client Software for Keyboard/Video/Mouse Switch control 3 User Guide / Bedienungsanleitung KVM series3-client Client Software for Keyboard/Video/Mouse Switch English / Deutsch KVM s3 Client Installer/User Guide Edition January 2006 Comments... Suggestions...


Burkhard Stiller Thomas Bocek Cristian Morariu Peter Racz Martin Waldburger (Eds.) Internet Economics II. February 2006

Burkhard Stiller Thomas Bocek Cristian Morariu Peter Racz Martin Waldburger (Eds.) Internet Economics II. February 2006 Burkhard Stiller Thomas Bocek Cristian Morariu Peter Racz Martin Waldburger (Eds.) Internet Economics II TECHNICAL REPORT No. ifi-2006.02 February 2006 University of Zurich Department of Informatics (IFI)


NI DataFinder Server Edition

NI DataFinder Server Edition NI DataFinder Server Edition Search Engine for Technical Data NI DataFinder Server Edition September 2013 374430H Support Worldwide Technical Support and Product Information ni.com Worldwide Offices Visit


NI DataFinder Server Edition

NI DataFinder Server Edition NI DataFinder Server Edition Search Engine for Technical Data NI DataFinder Server Edition July 2012 374430G Support Worldwide Technical Support and Product Information ni.com Worldwide Offices Visit ni.com/niglobal


Sartorius LMA300P LMA316PA / LMA321PA

Sartorius LMA300P LMA316PA / LMA321PA perating Instructions Betriebsanleitung Sartorius LMA300P LMA316PA / LMA321PA Microwave Moisture Analyzer Mikrowellen-Feuchtemessgerät Mat.-Nr. 98648-014-18 98648-018-36 LMA316PA / LMA321PA Englisch 3


Evaluation of the COGITO system

Evaluation of the COGITO system Risø-R-1363 (EN) Evaluation of the COGITO system V. Andersen and H.H.K. Andersen Risø National Laboratory, Roskilde August 2002 Abstract This report covers the deliverable D7.2 of the COGITO project. It


NI DataFinder Server Edition

NI DataFinder Server Edition NI DataFinder Server Edition Search Engine for Technical Data NI DataFinder Server Edition July 2014 374430J Support Worldwide Technical Support and Product Information ni.com Worldwide Offices Visit ni.com/niglobal


Program SUC 2013-2016 P-2 Scientific information: Access, processing and safeguarding

Program SUC 2013-2016 P-2 Scientific information: Access, processing and safeguarding Program SUC 2013-2016 P-2 Scientific information: Access, processing and safeguarding White Paper for a Swiss Information Provisioning and Processing Infrastructure 2020 Contact: isci@crus.ch Web: www.crus.ch/isci


A Division of Cisco Systems, Inc. Compact. Wireless-G. 802.11g. USB Adapter. User Guide WIRELESS WUSB54GC (EU/LA) Model No.

A Division of Cisco Systems, Inc. Compact. Wireless-G. 802.11g. USB Adapter. User Guide WIRELESS WUSB54GC (EU/LA) Model No. A Division of Cisco Systems, Inc. Compact 2.4 GHz 802.11g WIRELESS Wireless-G USB Adapter User Guide Model No. WUSB54GC (EU/LA) Compact Wireless-G USB Adapter Copyright and Trademarks Specifications are


Virus TI Series. Quickstart manual 5 Manual de iniciación rápida 49 Schnellstart Anleitung 93 Guide de démarrage rapide 137

Virus TI Series. Quickstart manual 5 Manual de iniciación rápida 49 Schnellstart Anleitung 93 Guide de démarrage rapide 137 Virus TI Series Quickstart manual 5 Manual de iniciación rápida 49 Schnellstart Anleitung 93 Guide de démarrage rapide 137 Virus TI Series Quickstart manual 5 Manual de iniciación rápida 49 Schnellstart


',3/20$5%(,7. Titel der Diplomarbeit: etom Enhanced Telecom Operations Map: Design und Erstellung von Telekom-Referenzprozessen.

',3/20$5%(,7. Titel der Diplomarbeit: etom Enhanced Telecom Operations Map: Design und Erstellung von Telekom-Referenzprozessen. ',3/20$5%(,7 Titel der Diplomarbeit: etom Enhanced Telecom Operations Map: Design und Erstellung von Telekom-Referenzprozessen. Verfasser: angestrebter akademischer Grad Magister der Sozial- und Wirtschaftswissenschaften


UPS WEB/SNMP MANAGER. CS121 Series. User Manual - English Benutzerhandbuch - Deutsch Rel.49

UPS WEB/SNMP MANAGER. CS121 Series. User Manual - English Benutzerhandbuch - Deutsch Rel.49 UPS WEB/SNMP MANAGER CS2 Series User Manual - English Benutzerhandbuch - Deutsch Rel.49 Limited Warranty This software and the enclosed materials are provided without warranty of any kind. The entire risk


LabVIEWTM. SignalExpressTM. Getting Started with LabVIEW SignalExpress. Getting Started with LabVIEW SignalExpress.

LabVIEWTM. SignalExpressTM. Getting Started with LabVIEW SignalExpress. Getting Started with LabVIEW SignalExpress. LabVIEWTM SignalExpressTM Getting Started with LabVIEW SignalExpress Getting Started with LabVIEW SignalExpress June 2009 373873E Support Worldwide Technical Support and Product Information ni.com National


IT-Outsourcing in Switzerland. IT-Outsourcing in der Schweiz

IT-Outsourcing in Switzerland. IT-Outsourcing in der Schweiz IT-Outsourcing in Switzerland IT-Outsourcing in der Schweiz Dr. iur. Roger Staub Nicola Benz Rechtsanwälte Attorneys at Law Avocats I T - O u t s o u r c i n g i n S w i t z e r l a n d I T - O u t s


Instruction Bulletin PowerLogic Ethernet Gateway EGX300 User s Guide

Instruction Bulletin PowerLogic Ethernet Gateway EGX300 User s Guide Instruction Bulletin PowerLogic Ethernet Gateway EGX300 User s Guide 63230-319-216A1 2/2009 ENGLISH TABLE OF CONTENTS TABLE OF CONTENTS... 1 INTRODUCTION... 3 Additional Resources... 3 ACCESSING THE EGX


Proceedings. Student Conference on Software Engineering and Database Systems

Proceedings. Student Conference on Software Engineering and Database Systems Proceedings Student Conference on Software Engineering and Database Systems 27th June 2009 University of Magdeburg G29-307 Database Track Table of Contents Current State and Future Challenges of Indexing


Internet Economics II

Internet Economics II Internet Economics II Burkhard STILLER Oliver BRAUN Arnd HEURSCH Peter RACZ (Hrsg.) Institut für Informationstechnische Systeme, IIS Bericht Nr. 2003-01 June 2003 Universität der Bundeswehr München Fakultät


English Intellex Digital Video Management System

English Intellex Digital Video Management System English Intellex Digital Video Management System Quick Reference Guide and Troubleshooting Guide Quick Reference Guide and Troubleshooting Guide Notice Copyright Customer Service The information in this


A Division of Cisco Systems, Inc. GHz 2.4 802.11g. Wireless-G. User Guide. ADSL Gateway WIRELESS WAG54G. Model No.

A Division of Cisco Systems, Inc. GHz 2.4 802.11g. Wireless-G. User Guide. ADSL Gateway WIRELESS WAG54G. Model No. A Division of Cisco Systems, Inc. GHz 2.4 802.11g WIRELESS Wireless-G ADSL Gateway User Guide Model No. WAG54G Wireless-G ADSL Gateway Copyright and Trademarks Specifications are subject to change without


A Division of Cisco Systems, Inc. ADSL2 Gateway. with 4-Port Switch. User Guide WIRED AG241. Model No.

A Division of Cisco Systems, Inc. ADSL2 Gateway. with 4-Port Switch. User Guide WIRED AG241. Model No. A Division of Cisco Systems, Inc. WIRED ADSL2 Gateway with 4-Port Switch User Guide Model No. AG241 ADSL2 Gateway with 4-Port Switch Copyright and Trademarks Specifications are subject to change without


GHz 2,4 802.11g. Wireless-G. User Guide. Broadband Router WIRELESS. with SpeedBooster WRT54GS (EU) Model No.

GHz 2,4 802.11g. Wireless-G. User Guide. Broadband Router WIRELESS. with SpeedBooster WRT54GS (EU) Model No. GHz 2,4 802.11g WIRELESS Wireless-G Broadband Router with SpeedBooster User Guide Model No. WRT54GS (EU) Wireless-G Broadband Router with SpeedBooster Copyright and Trademarks Specifications are subject


User Guide. KVM series3-1621 Keyboard/Video/Mouse Switch English

User Guide. KVM series3-1621 Keyboard/Video/Mouse Switch English User Guide KVM series3-1621 Keyboard/Video/Mouse Switch English control 3 USA Notification Warning: Changes or modifications to this unit not expressly approved by the party responsible for compliance


AXIS 5570e Network Print Server Installation Guide

AXIS 5570e Network Print Server Installation Guide AXIS 5570e Network Print Server Installation Guide ENGLISH FRANCAIS DEUTSCH ITALIANO ESPAÑOL Page 2 AXIS 5570e Installation Guide Take some time to read through the safety notices before installing the


A Division of Cisco Systems, Inc. GHz 2.4 802.11g. Wireless-G. User Guide. Broadband Router WIRELESS. with SpeedBooster WRT54GS (EU/UK/LA) Model No.

A Division of Cisco Systems, Inc. GHz 2.4 802.11g. Wireless-G. User Guide. Broadband Router WIRELESS. with SpeedBooster WRT54GS (EU/UK/LA) Model No. A Division of Cisco Systems, Inc. GHz 2.4 802.11g WIRELESS Wireless-G Broadband Router with SpeedBooster User Guide Model No. WRT54GS (EU/UK/LA) Wireless-G Broadband Router with SpeedBooster Copyright


UNIVERSITY OF TWENTE. Master Thesis. Cultural influences on the use of effectuation in entrepreneurship. The case of German student entrepreneurs

UNIVERSITY OF TWENTE. Master Thesis. Cultural influences on the use of effectuation in entrepreneurship. The case of German student entrepreneurs UNIVERSITY OF TWENTE Master Thesis Cultural influences on the use of effectuation in entrepreneurship The case of German student entrepreneurs Michael Drecker 17.02.2012 This thesis was written and handed