Hi!
Just a quick update, to bring some life to this blog, before it gets covered in dust!
This last Saturday hold the “Maratona JBoss”. It was an event organized by Tempo Real Eventos here in Brazil. It was very nice, covering performance, JBoss Seam and a success case. Nice!
Lunch Time - Claudinho, Alberto and Fábio
.. and maybe next time I should be in the picture as well… 
Paggo is doing great things with JBoss!
A few days ago, I posted here about the basics of working with mercurial. A little after that, Tor Norbye, from Sun Microsystems and The Java Posse, posted about his workflow with mercurial, a few problems he had with it, and how he solved these issues. I really like what he said, and I’m considering using the suggested workflow. If you are interested, take a look at his post.
The main issue is related to the fact that, more often than not, we need to commit part of the files we have changed in our projects, because we might be working on several things at the same time, and only one of them of ready to be committed.
But mercurial doesn’t seem to like this. So, to sum up the approach Tor now uses, you can work with two local repositories: one with the actual changes, and one exclusively to do the commits. When it is “commit time”, you “send” the files to be committed from the working repository to the commit one. See his post for the details.
I’ll try that out, let’s see how it feels 
We just made available here the initial code (only a draft right now) for the peer-to-peer project mentioned in this previous post. One of the things we decided to do differently from previous projects is to use an alternative approach for version control. So, we are switching from CVS to Mercurial. My goal in this post is to show what changes in the daily work using it.
The first thing to understand is that Mercurial is a decentralized version control system. So, each developer will have its own local repository. When you commit, you’re not committing to the server, but instead to your local repository. This is cool because this way you can commit very often, and without breaking anyone else’s code. Also, you can easily work offline (airplane, anyone?), and synchronize when you get internet access.
So, when you want to get the most recent version of the project, you pull it from the main repository. And then of course solve eventual conflicts. This allows you to be sure that your code is fine with the server’s, i.e. all the tests passes and so on. After that, you are ready to push your code to the main repository.
So, don’t forget that now, after commiting you code, it is NOT sent to the main repository just yet. It will only get there after you issue a Push from your local repository to the main one.
The exact way to do this will be different depending on the IDE you are using, but the concept is the same. Please consult the official site mentioned earlier and the documentation of your IDE for more detailed information. For NetBeans 6.1, for example, you can find something here.
