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.
Monitoring network traffic is a problem solved a long time ago, one might think. So why write the first entry in my shiny new Blog about monitoring network traffic? Well the answer is simple: because monitoring network traffic is a quite complex topic when multiple components, such as SSL, proxies etc. are involved.
Sure, almost every Linux user knows tcpdump, the intuitive solution for any basic monitoring need. Windows users might think of Wireshark or Proxomitron, for example. And for the Java people, there is at least Apache TCPMon which satifies basic monitoring needs.
All of these tools, however, could not satisfy my requirements:
Following a reader's comment on my earlier post, I found the new API (Extension point description of org.eclipse.ui.menus) which unifies all command contributions to Eclipse menus, views, objects, toolbars etc.
With this example it requires a lot less code to add an action (well, the new API uses commands) which is visible or enabled dynamically based on an object property. However, at the same time, we have to do quite a bit more extension configurations: Instead of a single declaration of an org.eclipse.ui.popupMenus extension, we need all this: