Dr. Stefan Winkler
freier Softwareentwickler und IT-Berater

Stefan Winkler's Blog

Separating the Wheat from the Chaff — Or: How to Sort Bugzilla Mails

One challenge in my daily work with my email is dealing with automated mails from Hudson or Bugzilla. As I am involved with several customer projects, I cannot keep track of all the Eclipse committer-related mail during the day.

As I am using GMail, I have become used to the mail filtering mechanism GMail offers to make email sent from Bugzilla or Hudson bypass the inbox and land in a separate IMAP folder (GMail uses a label metaphor, but when accessing mails via IMAP, GMail labels are mapped to IMAP folders).

Until recently, however, there was one problem, which I had not solved for months. As perhaps a lot of people do, I am not only receiving Bugzilla notifications related to bugs for which I am reporter, assignee, or on the CC list, but I also watch other Bugzilla accounts; most notably I, follow the This email address is being protected from spambots. You need JavaScript enabled to view it. Bugzilla notifications to keep myself up to date (at least theoretically ...) with all the current bugs of CDO. The problem was that I wanted to separate the more important notifications (those for which I am reporter, assignee or explicitly part of the CC list) from the less important ones (namely those to emf.cdo-inbox). Most of the time (and here comes practice ...), I have too little time to dig through all the Bugzilla notifications and identify the important ones which I should really care about (or at least read) right now.

Details
Category: Eclipse

Read more: Separating the Wheat from the Chaff — Or: How to Sort Bugzilla Mails

EclipseCon is over -- let's look forward to EclipseCon!

I had a great EclipseCon Europe with great talks, great people and as always delicious food. It was nice meeting and discussing with all of you. I was particularly fascinated how easy it is to start creating something physical on the basis of the Arduino Platform which has been demonstrated by David Cuartielles in his Keynote. When I have some spare time, I'll have to experiment with Arduino! BTW, if you are interested in cool stuff around Arduino, be sure to pay a visit to Makezine.com, a magazine website which shows amazing projects in that area.

Now, as I'm feeling like just coming home from one EclipseCon, the next one is only a short time away; and today is the deadline for talk proposals (So, if you are, like me, waiting for the last second, you should wake up and start writing now!). I actually woke up just yesterday and wrote two proposals which I have been thinking about for several weeks now, but never had to time to write down:

  • There and back again -- as quick as a flash will be a talk about the model persistence backend of CDO. I will present the different store implementations and give some insight on how they work. I'll also provide hints on how to tweak performance with the CDO persistence mechanisms.
  • Everyday Git will discuss what switching to (E)Git means in terms of the everyday development workflow. Together with Eike Stepper, we will have a look on how CDO handles things with (E)Git not so much on a technical level, but on an organizational/business process level.

I hope you find these talks interesting. If so, please drop by on the session proposal sites and add a comment and/or vote for the talks.

Details
Category: Eclipse

Migrating the CDO SVN repository to Git

The day has finally come. After months and days of living with the inconveniences of SVN (which, actually, we used to paise and worship after the days of CVS...), we decided to finally migrate the CDO repositories from SVN to Git.

In this blog entry, I will describe the steps we took to perform the migration. Before starting, however, let me summarize the history of the CDO repository, which leads to some of the specialities we have to deal during the migration.

CDO has been initially created and has lived for a long time in a CVS repository. Thus, we have worked with CVS branches and tags during a long period of our development. Then, the CVS repository has been replaced by SVN and the repository has been migrated and restructured to fit in the new SVN scheme. Also, to make everything cleaner, we have renamed and restructured branches and tags. We have also made use of SVN's capability to organize branches and tags in a hierarchical way (e.g. /branches/maintenance/2.0 or /tags/drops/S20100523-1540). Unfortunately, it became clear that hierarchical branches and tags would cause problems in the build and release infrastructure and so the structure was once again reworked into a flat structure, but this time with a canonical naming scheme to keep tags and branches manageable.

The challenge with SVN is here that it remembers tags and branches as they are at any point in time, even if they do not exist in that form in a later revision. In other words, if an SVN tag (or branch) exists for a particular revision, it will always exist if this revision is checked out later, even though the tag or branch might have been renamed, moved, or deleted in a later revision (and it is, therefore, not "visible" in the repository browser of the current SVN repository). For example, consider a branch in our repository which has existed as sw-rangebased-step1, then as swinkler/rangebased-step1 and finally as swinkler-rangebased-step1, depending on which revision you check out, the branch is still known by one of its older names. For the migration from SVN to Git this means that the migrated Git repository will end up containing all three branches. The same applies to tags as well. 

In addition to this, at some point, three artificial branches have been created in the CDO SVN repository: INFRASTRUCTURE, INCUBATING, and DEPRECATED. The purpose of these branches was to keep projects in the repository, which should not interfere with the main repository, for example, because they contain deprecated code. The additional goal of the migration to Git was to factor out these branches into separate repositories.

But enough talk about challenges, lets dive into the migration process. This process should be executable both locally and on a remote shell. For the CDO migration, an Internet linux server has been used (to have a suitably fast connection for the SVN access). So let's go ... 

Details
Category: Eclipse

Read more: Migrating the CDO SVN repository to Git

Finding the (almost) new Eclipse Tracing API

Last week I had to debug an Eclipse plugin of one of my clients. The plugin was already instrumented by a few simple tracing output statements here and there, as we know them all:

System.out.println("Entering fooBar()");

Because time was pressing, I followed this example during the debugging process. Afterwards, however, I had some time to refactor the code and I wanted to use the standard Eclipse tracing facility.

I had last used Eclipse tracing a few years ago. Back then, Eclipse tracing was done as described in the Eclipse FAQ by creating a .options file, putting the desired debug and trace options in there, and reading and storing the debug options in fields when the plugin was activated:

public static boolean DEBUG = false;
public static boolean TRACE = false;
 
public void start(BundleContext bundleContext) throws Exception {
	DEBUG = isDebugging();
	TRACE = Boolean.valueOf(Platform.getDebugOption(PLUGIN_ID + "/trace")).
}

In your code, you would then check for the value of TRACE and if the flag is enabled, you print out the message using println as above.

But the API has changed in two ways since then.

Details
Category: Eclipse

Read more: Finding the (almost) new Eclipse Tracing API

Page 4 of 5