Stefan Winkler's Blog
Sometimes it's the small things that make life a lot easier.
In my daily work, I found myself often writing code in the Debug perspective. When I noticed, I asked myself: Why?! Then I analyzed myself and found out that the UI element for switching back to the Plug-In Development perspective (which is the perspective I work in 90% of the time) after debugging something was just too hard to reach. I'd have to move the mouse cursor the long way over to the upper right corner of the screen, look for the Plug-In Development perspective button between all those open perspectives, and click it.
Ok, there is ⌘+3 (or CTRL+3 for non-Mac users) which you can use as well. But then you have to type a few letters to search and sometimes you intuitively select the wrong result etc. So, nah! – that's not it either.
But then it occurred to me: why not create a custom shortcut? I was in doubt whether you can assign a shortcut to a specific perspective, so I looked in the preferences and voilà:
So I quickly assigned ⇧+⌘+1 to the Plug-In Development perspective and ⇧+⌘+2 to the Debug perspective and now I can switch between both at light speed. I haven't thought about this earlier – I don't know why.
So the lesson learned today is: if you find yourself working inefficiently, step back for a second, analyze yourself and try to find a solution to fix it. Maybe the solution you need is only a preference setting away.
And I hope, the idea of assigning shortcuts to perspectives helps someone else out there ...
- Details
- Category: Eclipse
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
- Details
- Category: Eclipse
Read more: Separating the Wheat from the Chaff — Or: How to Sort Bugzilla Mails
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
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