Behavior change in 2.12 – FAIL!?

One important behavior change in 2.12 release was WinMerge now includes all files in all unique subfolders to the compare. Previous versions just showed that there was an unique folder.

Old behavior had many problems, we really didn’t know (and hence could not show) what was contained in those unique folders. Users complained when they could not copy/delete just certain items from those unique folders. It prevented developing many new features as the result set was just part of the reality.

In fact one very reason I finally implemented this was I can implement filtering for file copying. Meaning we apply file filters when copying items. That means user can set filter to filter Subversion’s .svn -folders. And when user then copies folders WinMerge does not copy those .svn folders. This is the feature I personally miss most. And seems many users agree it would be good feature, some even submit bugs about it.

So I thought I finally got it right when I re-wrote code to have all items in all unique folders included in compare results. It was a change I had been planning to implement past 5 years. And actually I had submitted couple of patches earlier but those patches weren’t good enough to commit. So I was actually quite happy that I got it done now.

Of course there are always users that are unhappy when something changes. I was expecting that and didn’t react to some complaints other than simply explaining it is the current behavior. Until I read this message in the forum saying new feature causes user’s usual compare times to grow dramatically (from under a second to 5-10 minutes). This was quite a shocking message to read!

And what is worse, there are no good solutions to this. I’m not sure if there are even sensible solutions we could implement. No way we go back to the old buggy behavior.

The problem is not just WinMerge – it is a lot more problem of operating system and hardware. OS and hw have caches that store last used disk data to memory to prevent slow disk access. But with this kind of huge folder structures most of the data must be read from the disk. And what is worse with WinMerge, we have two different folders structures when we compare, not just one. OS and hw caches assume programs use small set of files whose data can be kept in the cache. But then comes WinMerge and compares 100 thousand of files from two folders… And caches give up.

At the moment I don’t have any realistic ideas for solutions. It might be we can optimize the unique folders case somehow. Or delay reading the data, reading data in background etc. It is sure we need to do something…

Software is sometimes so fun!

First usable 2.13.x experimental release?

Few hours ago I released 2.13.4 experimental release. I hope this one is finally the first usable 2.13.x experimental release. Previous 2.13.x releases have each had some embarrassing (for me!) bugs. Of course I’m eating my own dog food and been using these releases. They are almost usable if one knows how to avoid those bugs and buggy features.

Perhaps the Most Embarrassing Bug I’ve been doing for a long time happened with 2.13.1. #2515875 “File->New” creates “disappeared” message in WinMerge 2.13.1. Funny (not really!) thing was that this bug was caused by my fix to another bug:  #2493945 Crash if one of the diffed file was erased by another applic. And that bug happened because my (thousand times checked) saving code didn’t check if the file really existed… Do you see the pattern? From rare crash bug we ended up to making  one of the most important features unusable. I’m always so proud when couple of hours after the release bug reports hit my inbox…

Sometimes I’m not sure which is more embarrassing, the fix for stupid bugs like these, or “thoroughly” tested fix that has funny side-effects.

The crash bug itself has been surviving few million users without reports until now. Which always begs the question if it really doesn’t happen for users or if they just don’t bother reporting it (as it is so rare). In this case I really hope it is the latter. As it is pretty easy to figure out situations when this happens. The simplest one being comparing files from removable media and then removing the media.

The only good thing is that my co-workers don’t see these bugs and mistakes… Oh, wait…

3500 commits (and six years)

Yesterday I noticed that my commit count in ohloh.net has reached 3500 commits. It is the amount of commits I’ve done to public Open Source repositories that ohloh.net tracks. It took about six years.

Now, that number is something one can proud of and it is public record. It is not the whole truth however. I don’t have easy way to prove it but I think my real commit count is over 4000. The reason? Ohloh.net tracks only commits to SVN trunk. So all branch commits are missing. We have sevenrelease branches in WinMerge and every release branch easily gets fifty or more commits by me. So 500 commits to branches sounds realistic. But as the 3500 is easy to prove and clearly visible it is better number to use.

Another unfair point with this number is that all commits are not for my work. I’ve just committed lots of work done by others. Translation updates are one example where I just commit work of others. I always give the credit in commit log (and in contributors listings) but again there is no easy way to tell how many my own patches I’ve committed.  However, I do some work for every commit. I build, test, review etc. So I think it is fair to say all these commits are my work too.

How about this another number, six years? When I contributed first patches for WinMerge I merely did it so that I could give back something. I never intended to become a regular developer. Indeed I did not even care if my patches were accepted or not. Of course it was nice they got accepted quickly. And the last thing I needed back then was taking responsibility from a software like WinMerge. I was using some Open Source software but knew very little about development models, tools and so on. It was totally new world and development model for me.

All that learning has been the best side of all this Open Source work. You must learn something new almost every day. It has been a big benefit in my day work too. Many times I’ve noticed at work that I already know the tools and libraries I need to use.

Everything I do is public. Every good idea and clever piece of code (when I some day write one…). But errors too! It is not nice when people see all errors and mistakes. There is no way to hide anything once it gets added to public repository. It was a bit shocking at first. Sometimes it is quite embarassing to find out that bug is caused by my own commit couple of years earlier. But I’ve never really seen finger pointing in WinMerge. Its not important who did it (error). It is important we fix it. This is one thing I really like in current development team.

It has been a fun six years with WinMerge. And although I need small breaks now and then I’ve no plans to stop contributing. There is so much work to do. WinMerge is good, but it could be so much better… For Frhed there are lot more serious alternatives, but I think it has its own good sides. Maybe it won’t be the best free hexaeditor but it will be one good hexeditor with some unique features.

Version numbering

Version numbers are always interesting topic. Although they really should not be. But people and users have used to things like “bigger version number always means better software”. Which is a bit uncomfortable for projects like WinMerge.

After all the version number is an identifier for the release. We could just give names for our releases (like some projects do). Problem with names is there is no clear clue about what is the latest release. And WinMerge project releases pretty often, several stable releases within a year.  So version numbers have their merit too.

We have been actively releasing experimental releases which naturally have bigger version number than latest stable releases. We’ve named them experimental releases, we’ve written warnings in release notes that they really are not stable release. Still people use them because they have bigger version  number. And even many download sites offer our experimental releases because the bigger version number. And it gets worse – I tried to add latest stable release for one download site but could not add a release with smaller version number than some experimental release!

We are changing WinMerge version numbering a bit. It should help with understanding our version numbers. Yes, current numbering sounded nice idea few years ago but it has became quite a pain. Back then we thought about “advanced” users who could figure out our system. But it has became painfully clear that many users don’t (bother) figuring it out but just download the version with biggest version number. No matter about categories or descriptions. Users want to use the latest and greatest version. Without thinking our nice numbering ideas.

It is hard to arrange releases so that the latest stable release will have the biggest version number. Only solution I could think of is using totally different numbering for unstable and stable  releases. But then the relation and order of releases would not be clear anymore.  I still want that we have linear release history so that certain unstable release series leads to stable release series. Unstable release series adds features and fixes for the next stable series. It is continuous development, not random hacking.

I personally feel it confusing that some projects use same numbering for stable and unstable releases. Sometimes I need to reads some release notes and changelogs to know if the release is stable or unstable as the version number and/or name does not tell that vital information. There are projects I don’t care being tester myself but use the stable releases. So WinMerge (and Frhed) will have clearly separated version numbers for stable and unstable releases.

In 2.13.x and later versions we only have three version numbers. First is two always. We aren’t ready to release 3.0 version of WinMerge. Actually I wonder when we could be. But updating version number to 3.0 would mean for users there is some real big changes. And I doubt we ever have releases with “big” changes. So we’ll stick with 2 for now on. Perhaps things like real cross-platform support or real 3-way merge could make the 3.0 release…

Second number is even (2.12) for stable releases and odd (2.13) for beta- and experimental releases.  Third number is just counter. It starts from 1 and we’ll increase it by one for each experimental release. For beta release we may bump it a bit more. For example first 2.13 experimental release was 2.13.1. Next will be 2.13.2 and so on. First 2.13 beta release will probably be 2.13.10 or 2.13.20, depending how many experimental releases we release before it.

This also means making the difference of beta- and experimental-releases smaller. They both are unstable releases from user’s point of view.  And we may in future just combine these two categories into one “unstable” category. Simplicity is good.

Configuring WinMerge for Mercurial

In earlier post I wrote about WinMerge and TortoiseHG. Unfortunately there is nothing new to tell about that. Mainly because I’ve been busy with many other things. But I’ll update the Todo item #2190215 TortoiseHG integration when there is something happening.

Meanwhile, there are instructions in Mercurial wiki about configuring WinMerge to work with Mercurial. The instructions assume WinMerge is in $PATH. After the installer this isn’t unfortunately true. Feature request for it is #2029425 Installer: option to add WinMerge to PATH and I’ve just submitted a patch: #2435175 Installer: Add WinMerge to system path.

The important part in the wiki page is how and what paths to give to WinMerge. This line describes it:

winmergeu.args=/e /ub /dl other /dr local $other $local $output

which looks lengthy so I’ll explain it briefly:

1. -e – tells WinMerge to close with single ESC key press
2. /ub – disables adding paths to MRU list in Open-dialog
3. /dl other - gives left-side file a label ‘other’
4. /dr local – gives right-side file a label ‘local’
5. $other and $local are paths to open
6. $output is the path where the merged file is written to

More about WinMerge command line in Online manual.

This command line format is what I’ve always looking for when I’m integrating WinMerge with some program. Now that the correct command line is known (to work) it is a lot easier to figure out rest of the pieces.

And if I understood tksoh’s comment in Todo item #2190215 correctly then we only need to add these settings for Mercurial, not for TortoiseHG.

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.

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.

Development slowing down?

Last couple of weeks have been quite slow development. Personally I was busy with other things. And the 2.10.0 stable release also took more time than I expected.

I still applied quite many patches. Most remarkable were the manual patches from Denis. Rest were version number updates and other stable release related stuff.

Now when the release is done I can get into normal development activities. Still there won’t be any big reworking coming in 2.12 release. I outlined 2.12 release in recent post to new development forum. We have lots of bugs to fix. And we really need to fix them.

Unfortunately the fact is there is only couple of active developers. And it seems most patches don’t relate to existing tracker items. It is very good people fix problems they find. But again, we really need to fix bugs already reported. Who wants to help me with that?

So if we only look at resolved bug items the development has slowed down. But I really hope it is only temporary situation. Not taking new features to next release should be a good hint about what kind of patches we need.

But if we look at number of commits they are increasing. We commit lots of cleanups and small improvements. These things aren’t visible for end users. Except sometimes as small speedups and GUI improvements. But these commits still make future development easier and allow easier and faster adding of new features.

What is the conclusion then? The development has not slowned down. Priorities and working methods have changed. Which may look like slower development.