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).
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:
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.
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 ...
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:
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:
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.