share the application schema: the SVN (subversion) connector [since
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
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
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
This repository function allows to compare the selected
administration objects with those stored inside the repository;
the process execution depends on 3 parameters:
||the comparison can be made with the repository
the last version (-1) or for another particular revision.
||when you check-out or update your local schema
from the repository, for each updated object, the platform registers
the current revision number inside the local database. During
the comparison, if this number results unchanged respect to
the repository version, the full comparison is skipped. Activating
this flag, OBEROn forces the full comparison even if the revision
number is the same.
NOTE: activate this flag if you change the repository location
because the stored SVN number is referred only to a specific
||comparison results are reported in the Result
tab in a textual form; activating this flag the objects which
result different will be added to the main Tab to facilitate
the update process.
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.
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
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.
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
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.
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.