share the application schema: the SVN (subversion) connector [since 1.6]

In software development, a software subversion (SVN), originally Apache Subversion, is a software versioning and a revision control system founded and sponsored in 2000 by CollabNet Inc. Developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly-compatible successor to the widely used Concurrent Versions System (CVS).
The open source community has used Subversion widely and the corporate world has also started to adopt Subversion.
A typical collaborative application consists of the source code written in a some program language and of a database schema. The code, in addition to user interface and other functionalities, is used to manipulate the information stored into the database according to the designed schema (usually by a language like UML). In complex projects, where more developers are involved, the code is versioned with a revision control system and, if a member of the development team performs modifications, new revisions are automatically generated so that other members can synchronize their local versions with the shared ones and find the differences.

When all developers have access to the same database, the database schema is obviously synchronized but, this ideal situation is not so frequent in the application development. Generally each developer, or a group of developers, works on a local database copy and modifications made on the schema must be replicated for all copies. This means that the database schema should be shared like the source code is; from this point of view, OBEROn offers a powerful collaboration tool to share the application schema through a SVN repository. Moreover, the platform allows to check and apply the schema modifications directly from the repository. Let see how:

Connecting to the SVN repository

If you want to share your application schema the first step is to set the SVN repository address and credentials in the Option dialog (or edit directly the configuration file oberon.ini ). After saved these informations, all the subsequent exchange operations will be made with the declared repository URL.

Synchronization with the repository

The repository synchronization allows to compare/update/commit your local application schema, or part of it, with one of the versions shared inside the repository. There are several ways to select administration objects to compare: maybe you need to check if your classes are all updated or if there are new classes defined by other users or maybe you need to check only specific elements. In the first case, you can select the administration object type (class,linktype,lifecycle...) from the left tree, otherwise you can select the specific objects from the same tree and finally open the contextual menu with a mouse right-click.

Moreover you can select the objects from the right tab where there are collected search results or dragged elements. In this case, you can use the repository commands from the main menu.

Compare...

This repository function allows to compare the selected administration objects with those stored inside the repository; the process execution depends on 3 parameters:

The following image shows how the found differences are managed when the "prepare update" option is active: in addition to the update OOQL command reported in the Result tab (command to make changes in the local database according to the repository object characteristics), the object is added to the SVN Update tab as you can decide if update it or not.

When you compare administrative objects like program, webservice and graph, the differences are computed also inside the source code (or the xml style) and reported into the Result tab. So, you can check the CHANGED / MOVED lines between the local code (L) and the repository code (R), or the lines ADDED / DELETED in the repository vesion compared to the local version.

Update...

The update function allows to check the object changes from the repository and to apply it to the local versions. The execution behaviour is very similar to the compare process, but the found differences (OOQL commands) are also applied to the local schema. You can decide to update from the repository the last version (-1) or from another particular revision number and you can choose if the comparison must be made in a forced mode, ignoring the svn numbers.

When the update command is launched for administration object types (field, class, linktype ....), the update process will check also if new elements of the same type were committed in the repository by someone else and, in this case, it adds them to the local schema. Otherwise, only selected administration objects will be affected by the update process. When an element is updated, the repository svn revision number is stored in the database.

Commit...

The commit process transfers the local changes and the new elements to the repository and generates new svn revision numbers for the committed objects. First of all, the process checks the differences between the local version and the repository version (if exists); the force commit option has the same meaning of that explained for the compare and update functions. Then, new elements and changed elements will be added/committed to the repository; the new svn revision numbers retrieved from the repository will be stored locally. You can insert a comment text for each commit process.

Properties

This function simply connects to the repository and extracts the last revision information for the selected elements; in particular you can check if the element exists and what are the current revision number, the last commit author and date.

History

This function is similar to the "Property" function but extracts more information for the selected elements; in particular the full commit history is retrieved from the repository: for each commit version you can check the commit author, the date and the comment message.