TortoiseHG and WinMerge?

In previous post I wrote about Mercurial. And I also mentioned the TortoiseHG as a Windows GUI for Mercurial.

For my embarrassment I have to admit I haven’t checked if WinMerge works with TortoiseHG. As I’ve been using Mercurial from command line I haven’t yet even installed TortoiseHG. I’ve downloaded the installer but haven’t had yet time to install and test it.

We are of course interested in supporting TortoiseHG and integrate with it. For WinMerge this integration means two things:

• WinMerge installer should be able to set WinMerge as TortoiseSVN diff/merge tool. With TortoiseCVS and TortoiseSVN it means writing some registry values. I assume it is similar thing with TortoiseHG.
• Figure out proper command line that TortoiseHG needs to give for WinMerge. This means starting WinMerge in “tool” mode and perhaps giving revision numbers as description texts etc.

I just submitted a new TODO item about this to our tracker: #2190215 TortoiseHG integration. If we are lucky, the next experimental release will have this integration.

Letting Mercurial help the development

Past months I’ve been using Mercurial distributed version control system (DVCS) to help my WinMerge development tasks. I can honestly say I couldn’t implement some stuff for WinMerge without using Mercurial. And I’m currently very much dependent on it for my WinMerge development.

This does not mean that we’ll convert WinMerge project to use Mercurial in near future. Subversion (SVN) is  good as a central source repository for WinMerge. SourceForge supports it and lately SourceForge’s SVN has became faster too. I don’t mind people publishing their work as Mercurial repositories, I can even pull patches from those repositories. But SourceForge’s SVN remains the official place for the sources.

I strongly recommend people to try Mercurial as a personal tool. As Mercurial and Subversion work pretty well together. The magic is in using hgsvn for converting subversion repository to Mercurial repository. And then getting further changes from SVN to Mercurial. Oh, almost forgot to mention Mercurial has a TortoiseSVN kind of interface, TortoiseHG for Windows users.

The initial conversion of the (WinMerge) repository takes quite a lot of time, but after that the process is very smooth. To decrease the initial conversion time one can only get revisions from certain revision onwards. I’d recommend converting latest 2000-3000 revisions at max from WinMerge repository. For just development there isn’t anything really interesting in commits made years ago.

So lets assume we have the converted repository available. How to work with it efficiently and where is the magic?

The biggest thing is having concept called local commits. You can do so many (and so small) commits as you wish, you can do as many errors and reverts as you wish. Without fearing to cause some mess into the main repository. Basically the idea is to track your work as you do it in local repository. I personally do a new commit every few minutes, even if my code doesn’t compile I just commit it. Other way to see it is creating frequent checkpoints of your work. If you do an error (oops, that change is buggy!) then you just see what you did after latest commit and perhaps revert that work. That is, revert few lines of code, few minutes of work. Instead of hours or days of work. Or just fix the thing with new commit without revert.

Which brings the second big advantage of Mercurial. It is very fast! Doing a local commit takes less than second. So it always takes more time to write the commit message than the committing itself. With subversion every commit may take minutes to do. You really don’t want to commit often with SVN. With Mercurial the committing is just a natural thing, like saving a file in the editor. But you get the full history of your work.

My personal workflow is like this:

1. update the local repository (using hgsvn) from SourceForge SVN repository
2. create a clone of the repository for the work
3. create a new branch into the new repository (I’ll explain the reason for branch below)
4. develop the feature/fix in the branch, do a lots of commits until the code is “ready”
5. create the patch by diffing the working branch and trunk (the SVN conversion) branches
6. submit the patch to SourceForge.net

Sometimes the patch gets finished with one try. Sometimes there is a bug or something missing and I’ll need to continue developing it. Then I:

1. update the trunk branch from SVN (to get latest commits)
2. merge changes from trunk branch to working branch (Mercurial does this)
3. continue developing the feature in working branch until it can be submitted to SourceForge.net again

This may needed to be repeated several times. But eventually it hopefully gets to the point when the changes are ready to be committed to SourceForge.net repository. The point in creating a working branch inside the repository is being able to easily see the changes between work in progress and the latest sources in SVN. Creating a patch is just one command. So the trunk branch in repository follows the official sources. Merging changes from SVN (trunk branch) to work branch makes sure you work against latest sources. Sometimes I don’t merge, especially if there are other changes to the code I’m working with.

So what if there is a bug or something still missing? Just repeat the steps above. Usually I’ll keep these working repositories around for some time. So if I need to continue work with the feature/patch I can first check how (and why) I ended up doing it the way I did it. Tens of small commits with good commit messages tell a lot more than one big SVN commit.

Merging is also one area where Mercurial shines. With CVS and SVN (and many other tools) merging is a task everybody is afraid of doing. It almost every time breaks something (if the merge isn’t trivial). Mercurial has advanced merge algorithm which itself handles lots of the merging work automatically. Sometimes it cannot determine what to do and then one can use some merge program (like WinMerge!) to do the merge. In DVCS tools the merging is very central action to do – it is routine. Not the flag-day action when all development stops until the resulting mess is sorted out.

There is no way I’m doing any bigger refactorings or changes for WinMerge without using Mercurial. There is some amount of work required to learn using the Mercurial and how to work with Mercurial and Subversion. But that is definitely worth of it.

Oh, and I know about Git. I’m using it too. It is a great tool, even faster than Mercurial. BUT it doesn’t natively support Windows (and WinMerge is Windows software). And I personally feel it is not so easy to use than Mercurial is.

Frhed 1.3.1 alpha is available

Few hours ago I uploaded Frhed 1.3.1 alpha release to the Sourceforge.net. This is the first Frhed release from me and new Sourceforge.net project.

Although I believe this is pretty stable and solid release, this is still meant being a snapshot of our current status. And give users something they can try and test. So what has happened after I took over the original Frhed project by Raihan Kibria?

I’ve re-created the installer with the latest NSIS version. I personally don’t like NSIS much but didn’t want to totally change the installer either. Maybe later.

Jochen has been doing a lots of refactoring and fixing. Lots of that is because of converting the editor part as an embeddable component (for WinMerge to use).

Tim submitted a new icon for the program. The old icon wasn’t so bad,  but it was just too old-style from W98 days. We needed something more modern and colorful.

Windows XP theming is now supported (the common controls manifest is embedded). So the application receives more modern-looking common controls in the GUI. The new icon and the new look are the really visible changes.

As this release shows we are really improving this software. It wasn’t just that I wanted to create a new Sf.net project. And we are improving it as a stand-alone software, not just as WinMerge component! I personally feel that Frhed as a stand-alone program is a lot more important than as embedded to WinMerge. But as a stand-alone software it probably gets few thousands of downloads. And as a WinMerge component it gets millions of downloads.

Unfortunately I haven’t had a time to really plan Frhed’s future plans yet. Basically I’m still figuring out things like manual’s format, building of the software etc practical things. Once I get the basic stuff sorted out I have to start thinking about Frhed as a software. And as a WinMerge component.

Lots of bugs?

Currently there are 165 bugs open in our bug tracker. That is quite a many open bugs. But is it lot or too many open bugs? For project like WinMerge?

It is lots of bugs and it is way more than I really liked us to have open. It is very easy to make fast conclusions like that WinMerge is not really a stable having so much open bugs. Or that our stability has decreased as there are move bugs open now than in some earlier time or release.

One thing I really like in working with Open Source is that all the data is available for everybody to look at. Even bug reports. We are not hiding anything. Quite opposite, if I find a new bug, I’ll submit a public report about it. Instead of hiding the info to somewhere in changelogs or release notes. So I think the WinMerge’s bug list gives quite a realistic view to our status. According to Ohloh.net’s code statistics tool WinMerge has over 400 000 lines of code. Yes, parts of the code is from external libraries, but still bugs in those libraries would be visible in WinMerge. So I think it is fair to say WinMerge has a very low bug count compared to its code size.

Another important factor is the severity of the bugs reported. There is a huge difference if the bug causes program to crash and user to loose data compared to typo in some dialog text. Both bugs are counted as one report. I wouldn’t want any of data lossage bugs in the software. But wouldn’t much care about few typos.

In WinMerge I think (haven’t really counted them lately) we have something like 10 open bugs that can really cause lose of the data. Couple of crashes too. Unfortunately it seems most of these are pretty hard to fix. Many reports miss the vital information and submitters don’t respond to the questions. Some bugs happen only with some certain machine (or at least they don’t happen in any developer’s machines) etc. Fixing these kind of bugs many times require just plain luck that somebody may happen to get more information or see the bug happen while debugging.

Still we have plenty of bugs we should be able to fix without much trouble. The problem is fixing bugs is a dull work. People want to add new features which adds something new and visible into the software. They want to be proud of adding some new cool feature. Instead of doing the invisible job of fixing bugs that most of the users don’t ever notice. And users also want new features. WinMerge has 349 open feature requests in our tracker. Realistically there are maybe 50 items we can really consider in some future release.

So what can we (or I) do to get more bugs fixed? Not much, in addition using my own development time for fixing those bugs. I have absolutely no interest to say to anybody that one must fix some bug. Nobody gets paid of developing WinMerge and I cannot say how people use their free time. I sometimes ask people to comment bugs I know they may have some idea about. Sometimes they submit a fix too. Which is very nice when it happens. But I don’t mind people just ignoring me – if they don’t want to touch that bug item its their choice how they spend their time.

My own time for real WinMerge development is quite limited. I do lots of other related stuff and more and more of my time goes into that. Like doing releases, updating documents, reviewing and applying patches etc.

One thing I did for 2.10 stable release was to declare it being a stability improvement release with only bug fixes and some minor other improvements. We didn’t add any big new features after 2.8 release to the 2.10 stable release. Instead lots of bugs were fixed. I think 2.10 development and release went pretty well, though I think there could’ve been more activity on bug fixing. Now I’ve already stated in the developers-forum that we must do this bug fixing release again in 2.12 release. There might be couple of new important features (binary file editor, tree-mode view in folder compare). But rest should be bug fixes and smaller improvements. I have big expectations about the 2.12 release. I personally really liked about the 2.10 release and 2.12 just must be a lot better.

This kind of “bug fixes only” mode easily de-motivates people. Which is the risk I’ve taken (again). But I honestly believe developers also want to be proud of the WinMerge’s stability and quality. And hence don’t run away when they don’t get to add fancy new features. WinMerge is something developers really can be proud of, no question about it.

Development of new features isn’t totally stopped. They can (and should be!) discussed and planned even though patches aren’t currently applied. In few weeks I’ll create a branch for the 2.12 release and then we can start applying the patches for the new features again. Which of course doesn’t mean that bug fixing stops…

So in my own opinion WinMerge is a safe and stable product to use. We have too many bugs open but I hope we get many bug fixed in next months and improve the situation making WinMerge even better product.

Visual Studio 6 support deprecated

Few months ago I wrote about supported compilers for WinMerge. And said we’ll deprecate VC6 as supported compiler. Since then there weren’t VC6 specific patches. Until couple of weeks ago somebody submitted patches to fix compiling with VC6.

Those posted patches showed very well why deprecating VC6 is the right thing. Marcel previously fixed our namespace imports and some other code cleanups. To get VC6 work we would have to revert these changes. No way I’d do that.

Previously I had stated that I can consider VC6 fixes if they don’t affect other code. Apparently that left room for some people to think we can make code uglier or add some hacks to get VC6 working again. So finally I stated that I simply won’t apply any VC6 specific patches anymore. No point in submitting such patches anymore, they won’t be applied. This is the final decision.

I know this upsets some people. And I know it can cause problems for some who for some reason want to continue using VC6. Unfortunately my only advice is you need to update your compiler. Or of course you can create your own fork of WinMerge and maintain VC6 compiling fixes in that fork. Just don’t expect we’ll merge such patches to our codebase.

Our challenge with WinMerge development is to make WinMerge more modern application. GUI is a bit oldish-looking. We lack many features people expect from modern editors etc. We must use our time with these things, not thingking how to support 10-years old compiler.

Sodan Tuulet

Viime päivät (lue: illat) onkin mennyt Sodan Tuulet -sarjaa (Eng: Winds of War) DVD:llä katsellessa. Vaikuttavin sarja mitä on vähään aikaan tullutkaan katsottua. Ko. sarjan boksin ostin jokin aika sitten heräteostoksena Anttilasta. Ja eipä kyllä kaduta tippaakaan.

Itse asiassahan tuo on mini-sarja, ja useimmat jaksot kestävät yli kaksi tuntia (jakso per dvd). Mutta siltikin tuntuu että niin paljon jää kertomatta tarinasta. Ja tietenkin koko tarina jää pahimmoilleen kesken. Olisikin todella hienoa kun saisi jatko-osan Sodan Muisto:nkin (War and Remembrance) katsottavaksi. Valitettavasti tuota ei ole (vielä) julkaistu Suomi-boksina.

Nämä molemmat sarjat perustuvat Herman Wouk:n kirjoihin. Luin tuon Sodan Muisto:n muutamia vuosia sitten. Lukemistahan siinä riittää tuhannen sivun verran. Mutta eipä sen kanssa aika käy myöskään pitkäksi. Vaikka meritaisteluiden kuvaaminen ja strategioiden selittäminen välillä onkin aika hankalaa ymmärtää. Ehkä se tarkkuus sopisikin paremmin jonnekin tieto-kirjaan eikä romaaniin.

Niin, itse tuosta Sodan Tuulista. Vaikka näitä sota-tarinoita onkin viime vuosina tullut “tarpeeksi” (Taistelutoverit, Pelastakaa Sotamies Ryan, Schindlerin lista jne) niin siltikin omasta mielestäni tämä on kuvauksena mielenkiintoisin (ja minä pidän Taistelutovereistakin). Koska sarjassa ei kuvata itse sotaa, vaan ihmisiä jotka vaan joutuu ns. pahaan paikkaan. Ei tarvitse mässäillä verellä tai komeilla räjähdyksillä, kerrottavaa riittää muutenkin.

Tarinasta on huono kertoa ilman että tulisi paljastettua liikaa. Mutta sanotaan nyt vaikka että keskeisimmät toisen maailmansodan tapahtumat itse sodan valmisteluista Pearl Harbouriin käydään läpi. Ja joku päähenkilöistä on aina jotenkin mukana tapahtumissa.

Seuraavaksi pitänee hommata Sodan Tuulet myös kirjana. Jotenkin voisin kuvitella että tarinaan sisältyy paljon enemmän kuin mitä TV-sarja pystyy kertomaan. Sitten pitäisi jostain löytää aikaa lukea se… Noh, junassa istumistahan on tiedossa…

Jos on katsomisesta pulaa, hommatkaa tämä sarja. Jos on lukemisesta pulaa, hommatkaa jompi kumpi kirja.

Facebook and RSS-readers

Some time ago I added RSS application called Simply RSS to my Facebook profile. It worked pretty well with my blog’s feed. But I think after Facebook update it stopped updating. I even tried to install another RSS application but could not get it working either.

I hope this does not mean that RSS applications don’t work with the new Facebook? Not sure about the application model with Facebook, but maybe apps don’t “run” when they are shown (page opened). If I open the Simply RSS’s options and ask it it update, it works. Otherwise it won’t update feeds.

Feeds are very handy way to keep up with lots of different web sites, news and blogs. Especially the blogs are getting more and more important in spreading the information. Currently I’m using FireFox add-on to read feeds. But it would be cool to get feeds appear as one Facebook page. It would mean (once again) less applications to use and less web pages to open to get the information.

But I quess for the Facebook (and big public) it is more important that those endless quizes and games work… I definitely need to know what Disney character I am (based on couple of questions) and how perfect life I have based on few weird questions… Instead of getting latest news and information I really need.

I don’t want to give up (yet) so I’ll try to find a working RSS application or configuration that works with Simply RSS application.