In any software development environment, it's important to be able to track the way in which an asset has changed over time. Developers make use of version control systems to assist with this task, and rely on “diff” tools to be able to easily target exactly how a file has changed between revisions. StreamBase applications are no different, and StreamBase Studio 5 introduces several new features aimed at making this easier and better for developers.
In addition to being able to manage and model changes to an individual file (discussed in detail below), developers also need the flexibility to store StreamBase source files in an arbitrary location on the file system, so that they can easily integrate with their organization’s version control system structure. StreamBase 5 now allows source files to be stored outside of its workspace directory structure, such as in a developer’s local copy version control repository. This permits developers to efficiently manage the versions of StreamBase artifacts, even in an environment in which the version control mechanism is external to some or all of the IDEs used by development team members.
StreamBase Studio 5 is built as a set of plug-ins to Eclipse 3.2, thus version control of application artifacts created by Studio will be achieved in the same way as with other Eclipse tools - namely, via any Eclipse-compatible version control system, such as CVS or Subversion. Specifically, any version control plug-in will now be able to natively manage StreamBase artifacts, directly within the Studio environment. The user simply has to place StreamBase application source files in a project folder managed by Eclipse.
Comparing Changes Between Versions of StreamBase Artifacts
Let's explore the ways in which StreamBase Studio helps you compare how an application has changed over time.
All StreamBase application files are encoded in textual format, rather than a binary format. StreamSQL applications are stored as pure text, and EventFlow applications are stored in XML format. Text is very amenable to version control, because “diffing” text—that is, determining the differences between text files—is relatively easy. Diffing XML is more difficult than plain text, but there are tools available that can help.
The key to understanding how an EventFlow application could change is to note that the application source file contains both semantically meaningful application control and logic, as well as semantically meaningless layout information.
That is, the EventFlow file specifies the relationship of application elements; for example, what is connected to a given node, what is downstream or upstream from it, and so on. But while the topology of the graph has semantic meaning, not all changes to an EventFlow file change its topology. For example, when you change only the position of an element represented in the GUI, but do not its topological relationship with other GUI elements, the application’s semantic specification has not changed. But because the X and Y coordinates of a GUI element are captured the application source file, a change in an element’s position shows up in the generated source as a change in its X/Y coordinates. Such changes don't impact the application's functionality, but do affect how the application is displayed in Studio.
To address this, StreamBase 5.0 has extended Eclipse’s version comparison capabilities by including a “semantic filter,” which lets you hide or expose these kinds of layout changes, which are not semantically significant. The use and appearance of the semantic filter function is described in more detail below.
The example compares an application with a previous version, from the Eclipse-managed Local History list. Note that you also select and compare two different files, or files managed by a version control system.
Begin by displaying a StreamBase application within StreamBase Studio. You do not need to create the application shown below—any application will do. The application shown is very simple indeed, it consists of a single input stream, a filter, and three output streams:
-
The input stream schema contains a single integer, just_an_int. The app directs the input tuple to one of three output streams based on its value.
-
The filter tests the value of just_an_int, delivering the tuple to Output Stream 1 for values between 200 and 800, to Output Stream 2 for values greater than 800, and to Output Stream 3 for values less than 200.
We'll now make three simple changes to the application. The first change alters the logic of an existing element; in this case, making the first Filter1 predicate select integers between 500 and 1000, instead of between 200 and 800. The second change renames OutputStream1 to “Integers_of_interest”. And the third change simply changes the location position of InputStream1 on the canvas.
The two figures below shows the Compare tool's representation of the changes that have been made. This comparison is invoked by right-clicking on the sbapp resource, or on the application canvas, and choosing Compare With...Local History. This will display the Compare with Local History window, shown below:
(click images to zoom in)
Clicking on the various application components int the upper right pane controls what's displayed in the two comparison panes. Clicking on the App icon displays all changes in the entire application, while clicking on an individual operator will just display changes to that operator in the compare panes.
The figure above illustrates the name change from “OutputStream1” to “Integers_of_interest” as well as the changes made to the logic of the Filter operator.
Note that the StreamBase EventFlow Application Compare pane (the upper right-hand pane) also lists “Input Stream [InputStream1]” on the first line beneath “App.” This entry represents the change made to the position of the InputStream1 icon.
Now note the filter button at the top right of the StreamBase EventFlow Application Compare pane. This toggle button determines whether or not the comparison shows semantically meaningful changes. When this button is clicked, the semantically insignificant change of position of the InputStream1 is hidden:
(click image to zoom in)
If you toggle this button again and then select the “Input Stream [InputStream1] line, the Compare Editor displays the actual changes in X and Y coordinates for the InputStream1 element
(click image to zoom in)
You can now see the new X and Y coordinates for the element that was simply moved. If you reapply the semantic filter, that information is again hidden.
To recap, changing the logic of an element, adding a new element, or adding a new branch to the application, all result in semantically meaningful differences. Note that the Compare tool displays a rename operation on an element as a semantically meaningful difference as well (even though a rename has only a limited semantic meaning because element names are primarily an aid to human understanding). In contrast, simply changing the position of an element has no semantic value or meaning.
Configuring Local History
Eclipse manages the Local History capability, and provides several configuration parameters. These can be reached from the Window menu: Window...Preferences, then choose General...Workspace...Local History. From this panel, you can configure the number of days to retain files, the maximum number of files, and the maximum file size.
Related Topics
For complete information about the capabilities of the Compare tool, see the StreamBase Authoring Guide.