Review of Guiffy SureMerge

Date: March 2006
Product: Guiffy SureMerge 7.2 “Dogwood”
Vendor: Guiffy Software (http://www.guiffy.com)
Reviewer: Austin Hastings

Bill Ritcher, coder and CEO of Guiffy, is aware of the review. He became aware about half-way through when I was contacting him for help with various issues. After the review was published, Guiffy began providing a link to the review from their product web site.

Guiffy (pronounced “Goofy” according to owner/developer Bill Ritcher) SureMerge is a java-based, platform-neutral visual compare and merge utility for software and content developers. It is compatible with Java 5 (as well as earlier releases) and is available for OpenVMS and OS/2, as well as less-popular operating systems like Linux, Windows, and Mac OS/X.

Most of the time, comparison and merge tools are listed as being tools for developers. In reality, though, this is not true. Comparison and merge tools are tools for leads, build managers, and SCMs—the folks who get called when something goes wrong. But we all wish that developers would fix the problems they introduce, so most companies distribute these tools to everyone. SureMerge supports developers with “the usual” range of compare and merge features, discussed below. In addition, it contains features that will be near and dear to the heart of build managers, team leads, and change managers everywhere—tools that make it easy to deal with whole development teams and whole trees of files.

The product comes with a collection of executables including stand-alone compare and merge command line tools. One of those programs is a command-line merge utility called suremerge. The GUI version is named guiffy. I will refer to them by name when it is relevant. Otherwise I will call the whole software bundle SureMerge, and the company Guiffy.

Two-way comparison of files is what comes to mind immediately when you think about comparisons: put two files next to each other and see where the changes are. Most readers will be familiar with the diff and sdiff commands for comparing files and displaying the results. A graphical rendition is much clearer and easier to understand.

When you evaluate SureMerge, the Guiffy web site (http://www.guiffy.com) includes a white paper with a series of test cases. The white paper highlights different kinds of changes and how they are handled by merge & compare tools, using Guiffy source code in the examples. This screen shot was taken using one of the included test cases. (No, I don't have access to Guiffy's source code.)

A very nice feature of the guiffy GUI 1) is character-by-character highlighting of differences. If you are using a language that tends to have 'dense' statements, this can be a life-saver, highlighting where a full stop ('.') changed to a comma or where a single quote became a back tick. Be careful with character-by-character differencing: like all compare algorithms, it is prone to look for similarities that may not be there:

The example shows two random DNA sequences. I used perl to randomly emit the four letters A, C, G, T. As you can see, guiffy was willing to “walk a mile” to show me the exact changes, when in fact I just made up two totally different sequences. 2)

That was a dumb example made to demonstrate a point: guiffy offers a configuration setting that lets you determine how much change is “too much”. A better example is refactoring code. Consider this change, taken from Michael Schwern's excellent Perl refactoring tutorial:

This example also has character highlighting turned on, so what happened? The answer lies in a configuration dialog, Options>Show:

You can choose to show difference that are up to 100% of the line, which is what I did for the DNA sequence above. The default is 50%, as shown, but when you are merging source code the devil is in the details. In the example above, line 9 changed by more than 50% because of the long variable names. As a result, it was “too much change” to highlight. With a single buttonpress, a mouseclick, and 'Enter' I have a different picture:

This is how the same code looks at a 75% change cutoff. Suddenly it's clear that the perl variables have been pulled out of the SQL statement and replaced by bind variables. And the variables are now passed to $sth→execute as method args. This is great stuff! Just to be a little nit-picky, I'm going to suggest that Guiffy make the Show Options page into a toolbar control or some kind of dockable: when you are looking at differences in code it can be important to quickly toggle back and forth.

Beyond two-way comparison lies three-way. (Relax: three is the limit!) With three-way comparison, and three-way merging, you are comparing a single common ancestor with two different changed files. This is the tool to use when two developers have made different changes to the same file, and you're stuck merging them together. Sound familiar?

In the illustration (below) you can see how guiffy presents two changes that conflict with each other. In this case, different developers have allocated the constant value 7 to different purposes: the names CWP and ENA.

To merge the changes it isn't sufficient to copy both new lines into the resulting file. Instead, one line will have to be manually edited to convert its value from 7 to 8. The tool compares both changed files against the parent, and then compares the change sets. For each part of the file, the possibilities are:

Nearly all merge programs use this kind of logic to determine how to respond to changes. There are a couple of potential problems, however. First comes finding the smallest region in the file that constitutes a single change. We've all seen cases where a compare program finds a single closing curly brace that is “equal” to similar text in the other file and so declares that point the end of one change and the start of another. Finding the boundaries of a “single” change can be challenging.

Some cases aren't so clear-cut. For example, what if two developers insert code in the same location in the file, as illustrated above. You or I can tell it's a conflict (two allocations of the number 7), but some tools won't, since the two changes can be automatically merged by inserting both! The white paper I mentioned above has 5 simple scenarios for compare & merge. I was surprised to learn that every other tool in the market gets at least one of those scenarios wrong! The cases are simple, and source code is provided: try them yourself.

Knowing what to ignore can be an issue, too. If the files in question have been translated from one operating system to another, or edited with different tools, things like white space and line terminators may be different. Having the ability to ignore these trivial changes is important. SureMerge has the ability, in spades. You can ignore whitespace at the beginning, at the end, or everywhere in the file. You can ignore changes matching a regex, or changes in a certain range of columns. The only thing SureMerge won't ignore for you is phone calls from your boss.

Finally, there is the risk of an identical-but-wrong change. In this scenario, possibly caused by out-of-band sharing, one part of a change might be present in both child versions but be fatal to one of the changes. Typically, you'll see this when the two developers have discussed the changes but haven't explicitly thought about each change. There's no way to catch these mechanically—your best bet is good unit testing.

guiffy does offer a nice feature that comes close to being psychic when these changes happen within a few lines: it reports an 'attention' on code changes that are not in conflict, but are close together. If two developers made changes just a few lines apart, the software knows that it could merge them automatically, but is smart enough to say, “Hey! Somebody should check this.” Just like the Federal Aviation Administration, it considers even a near miss to be something important. Very nice.

As you might expect from a product named SureMerge, merging is a strong feature. There are a lot of different ways you can “merge” code via the GUI:

1. Just start typing. If you are using guiffy in merge mode, type (or copy & paste) what you want into the “merged” window—guiffy won't let you change either of the original inputs. If you are using compare mode, you can edit in either file just like a text editor.
2. Use Two-way merging. If all you have is two different files, you can choose between alternatives: Of course, you can also just type: sometimes the merge process isn't about selecting between two alternatives, but combining them. If you need to type, or copy and paste, to get the results you want, just point and click.
3. Use Three-way merging. As mentioned above, guiffy is excellent at determining just exactly which changes can be merged automatically, and which changes really do require the attention of a human. Of the five scenarios described above, only 1 requires a human to help with the work. In my experience, this reflects reality fairly well: I'd guess that the number of 'real world' merge steps requiring human attention is somewhere between 5 and 30 percent, depending on your code.

Regardless, guiffy gives you the same basic interface (the 'parent' is used to compute the changes, but isn't shown) as with two-way merging, and lets you do the same things: select code from either source as a starting point, then edit the code to the result you want.

Another nice feature of guiffy is the directory tree compare GUI. This uses the same color scheme as the file compare to show you files that have been added, deleted, or changed between two directory trees:

This is a great place to start when you are trying to understand what has happened to your code. Seeing the higher-level view of what has been changed lets you organize your approach to understanding and/or merging the changes. The interface is visually clean and attractive, as well as intuitive. The obvious tools to fix to directory tree issues—copying, renaming, and and deleting files—are supported in the tree view. I do have a few gripes about this interface, however:

• First, there is no indication at the directory level that children have changed. For a deep source tree this may make it harder to grasp the whole impact of a change. Mitigating this is the fact that the GUI takes you right to the first change, and you can use the next/previous change buttons to navigate.
• Second, guiffy doesn't do the “obvious” thing when dealing with trees. If I invoke guiffy with three or four directory names, as I would do for merging files, the tool doesn't automatically create the new “merged” directory tree. Neither does it correctly populate the “parent” field when I try to SureMerge a changed file.

The former is evidence of how addictive and intuitive the rest of the product is: of course it will work this way—just bring up the directories and start resolving conflicts! It actually took me a while to grasp that I was wrong. The latter behavior—incorrectly populating the parent field—seems to be just a bug. guiffy remembers the last value I used, instead of populating it from the command line.

• Third, there is no good way to move files from one directory to another: the 'move' operation is an extended version of 'rename'. I suspect this is a drag & drop problem—there are some other issues with drag & drop discussed later. For Java development in particular, this may be a problem when refactoring. (Or not: much refactoring will involve opening the 'rename' dialog anyway—maybe combining move with rename won't be a problem.)

In addition to fast, accurate 2- and 3-way merging, SureMerge includes

• jiff – a command-line compare utility

• suremerge – a command-line merge utility

• Recursive comparison of directory hierarchies in guiffy and jiff

• HTML comparison reports in guiffy

• Support for international character encodings

• A Java API for integrating SureMerge functionality into your own programs.

• Really responsive support

There's a wealth of other features listed at http://www.guiffy.com but these stand out as being important for automation and build/team management.

jiff is not diff. Instead, it is a command-line tool for showing differences. It does not use the diff algorithms (a feature: Guiffy claims their algorithms are better), it does not produce the eleventy-four different specialized formats for feeding to other tools. It does not use the same command-line switches: another feature, since diff does not have a switch for specifying the character encoding of the input files, while jiff does.

What jiff does is produce a very readable, very comprehensible text version of the results shown by the guiffy GUI. Here's an example:

C:\\temp\\Guiffy review\\perl>jiff db2.pl db4.pl
  1  1 open (INPUT, "< $filepageid") || &file_open_error("$filepageid");
  2  2
  3  3 while ($riga=<INPUT>){
  4  4     $nump++;
  5  5     chop($riga);
  6  6     $pagina[$nump] = $riga;
  7  7
  8   <    $sth= $dbh->prepare("SELECT count(*) FROM lognew WHERE
  9   <                         pageid='$pagina[$nump]' and data>='$startdate'");
 10   <    $sth->execute;
 11   <    $totalvisit[$nump] = $sth->fetchrow_array();
     8>    my $totalvisit_sth = $dbh->prepare('SELECT count(*) FROM lognew WHERE
     9>                                        pageid=? and data>=?');
    10>    $totalvisit_sth->execute($pagina[$nump], $startdate);
    11>    $totalvisit[$nump] = $totalvisit_sth->fetchrow_array();
 12 12

jiff offers a directory-compare behavior similar to guiffy, but I had a few problems with this.

• First, I expected jiff -r to behave just like diff -r: that was arguably my problem. Instead, jiff -r does just a tree comparison: it does not show file differences as it goes.

• Second, getting jiff -r to show files that have changed between the two trees requires specifying the -bxt (Verify files match) option: this one even stumped the author for a while. 3)

• Third, the option syntax is awkward: -diffs shows “only the differences” for files, but -nomats shows “no matching files” for folder comparisons.

• Finally, the folder compare wants to show the names of folders it has checked, even if there were no differences: -nomats didn't prevent it from burying my file changes amid a maze of directory names, all alike:

    <DIR>     10-Apr-2006 22:48:55 libs
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action\\controller
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action\\controller\\http
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action\\controller\\session
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action\\controller\\templates
    <DIR>     10-Apr-2006 22:48:45 \\libs\\action\\view
    <DIR>     10-Apr-2006 22:48:46 \\libs\\active
    <DIR>     10-Apr-2006 22:50:47 \\libs\\active\\record
<       4,284 10-Apr-2006 22:55:50 \\libs\\active\\record\\Field.php
<          13 10-Apr-2006 22:50:47 \\libs\\active\\record\\NewFile.php
>       4,288 10-Apr-2006 22:56:24 \\libs\\active\\record\\Field.php
    <DIR>     10-Apr-2006 22:48:46 \\libs\\active\\support
    <DIR>     10-Apr-2006 22:48:46 \\libs\\configurator
    <DIR>     10-Apr-2006 22:48:46 \\libs\\context
    <DIR>     10-Apr-2006 22:48:53 \\libs\\creole
    <DIR>     10-Apr-2006 22:48:48 \\libs\\creole\\common
    <DIR>     10-Apr-2006 22:48:48 \\libs\\creole\\contrib
    <DIR>     10-Apr-2006 22:48:53 \\libs\\creole\\drivers
    <DIR>     10-Apr-2006 22:48:49 \\libs\\creole\\drivers\\mssql
    <DIR>     10-Apr-2006 22:48:49 \\libs\\creole\\drivers\\mssql\\metadata
    <DIR>     10-Apr-2006 22:48:50 \\libs\\creole\\drivers\\mysql
    <DIR>     10-Apr-2006 22:48:50 \\libs\\creole\\drivers\\mysql\\metadata
    <DIR>     10-Apr-2006 22:48:51 \\libs\\creole\\drivers\\mysqli

Where jiff would accept a relative path on the command line, like jiff med2\\libs\\active\\record\\field.php med3\\libs\\active\\record\\field.php suremerge would not. Needless to say, suremerge and I did not get off to a great start.

In addition, it has problems parsing directory names that include spaces on Windows. When I specified a directory with a leading quote, as “C:\\MyDocuments\\Sources\\Php Data Layer”\\med2\\… all was well. If I tried to use quotes inside the directory, as C:\\MyDocuments\\Sources\\“Php Data Layer”\\med2\\… then I got a usage statement, and eventually a sore forehead from banging it against my desk. This is documented in the help text, but it's just a little bit different from common Windows behavior.

Apparently, suremerge makes no use whatsoever of the current directory. It does not resolve relative paths against it, and it will not use it to resolve its output file, either. Once you overcome these challenges, though, suremerge does just exactly what you expected it would do: it performs the same merges from the command line that guiffy does from the GUI. The remaining problem, of course, is when lines conflict with each other. Anyone who has used CVS will be familiar with the result:

<<<<<<< C:\\mydocuments\\Sources\\php data layer\\med2\\libs\\active\\record\\Field.php
class Field extends Object implements Persistable {
=======
class Field extends Object 
	implements Persistant 
{
>>>>>>> c:\\mydocuments\\Sources\\php data layer\\med3\\libs\\active\\record\\Field.php

Because of Guiffy's improved algorithms, suremerge will have fewer of these conflict spots than other tools. And once you get the command line quirks figured out, it's easy to script around them. But it's still awkward: effective, but awkward.

The guiffy tree comparison feature is a very nice way to get a sense of what has changed in a project. Automatically generating an HTML document that looks like the GUI would be really nice. Putting the changes out where everyone can see them provides the kind of easy visibility that is important when project members aren't working tightly together.

guiffy's HTML reports don't look exactly like their GUI counterparts, but they sure are close:

The changes are highlighted using the same colors as the GUI, including the character-by-character highlighting. Obviously you can't change the highlight options in mid-stream, as you can with the GUI.

The directory comparison is a little less close to the GUI. It doesn't show the folder tree view. Instead, it looks more like the output of jiff -r. Regardless, it gets the information across:

The HTML reporting capability seems new, according to the release history, and I found some rough spots that support this:

• Did you notice that the header says the folder compare report was produced by version 7.3—yet this is supposed to be a review of version 7.2? Well, I've got a beta! I found a bug in the HTML reporting: guiffy hangs when asked to generate folder reports in version 7.2. So I'm looking at an early image of the next version. (I didn't install the new .jar until time to come back and finish this section. Everything else for this review was generated on 7.2.)

• I also found a problem with long lines. In the image below you can tell that a character has changed in the left file (because of the red color) but you can't see what it is:

This is a Firefox problem, though, not a Guiffy problem. The same page looks fine in Internet Explorer 6.0:

I had a look at the generated HTML, and it's clean. I think this one is a Firefox (actually, Gecko rendering engine) error.

• Finally, errors like invalid filenames (or missing files, if you prefer) don't return a status code, they display a dialog box. This is definitely not good for a scripted solution.

• This is a feature request, but I think it would make sense for the HTML report generator to produce a whole web of linked comparison reports: specify a switch, and get a whole series of output files, hyperlinked together, showing all the changed files.

The format of the generated HTML is very clean, and uses CSS tags for displaying changed entries. I think that a good perl coder could probably get the linkages going in a day or so. But it would be better if he didn't have to.

Consider this image of a guiffy compare of two versions of a file

What's interesting about this result is the nature of the inputs: one of these files is encoded as a plain old ASCII text file (technically, Windows codepage 1252) while the other is UTF16. Here's a different way of looking at them:

C:\\MyDocuments\\Sources\\Php Data Layer>sed -ne 41p field.uni.txt|od -t x1z
0000000 00 63 00 6c 00 61 00 73 00 73 00 20 00 46 00 69  >.c.l.a.s.s. .F.i<
0000020 00 65 00 6c 00 64 00 20 00 65 00 78 00 74 00 65  >.e.l.d. .e.x.t.e<
0000040 00 6e 00 64 00 73 00 20 00 4f 00 62 00 6a 00 65  >.n.d.s. .O.b.j.e<
0000060 00 63 00 74 00 20 00 69 00 6d 00 70 00 6c 00 65  >.c.t. .i.m.p.l.e<
0000100 00 6d 00 65 00 6e 00 74 00 73 00 20 00 50 00 65  >.m.e.n.t.s. .P.e<
0000120 00 72 00 73 00 69 00 73 00 74 00 61 00 62 00 6c  >.r.s.i.s.t.a.b.l<
0000140 00 65 00 20 00 7b 00 0d 00 0a                    >.e. .{....<
0000152

C:\\MyDocuments\\Sources\\Php Data Layer>sed -ne 41p field.php|od -t x1z
0000000 63 6c 61 73 73 20 46 69 65 6c 64 20 65 78 74 65  >class Field exte<
0000020 6e 64 73 20 42 61 73 65 20 69 6d 70 6c 65 6d 65  >nds Base impleme<
0000040 6e 74 73 20 50 65 72 73 69 73 74 61 62 6c 65 20  >nts Persistable <
0000060 7b 0a                                            >{.<
0000062

As you can see, the two files are totally different internally: two different character sets, two different encodings. By telling guiffy about the file encodings of each file—via the command line or a dialog box—the compare engine knows to ignore the encoding and focus on what's important: the contents of the files!

guiffy allows you to separately specify the encodings of the two primary files, the optional parent file for 3-way compare/merge operations, and the output file for merges. I recently worked at a client site where we would have been thankful just to be able to specify the input encodings: what a shame we didn't have guiffy.

One of the problems with multibyte characters is how to deal with “broken” or invalid character sequences. guiffy handles them fairly well: the invalid sequences are displayed as invalid characters. In this scenario you're probably going to need to hex dump the bytes to see exactly what went wrong (unless you just go fix the program that produced them).

The support for output encodings even extends to HTML reports. Specifying the output encoding produces an HTML document with the correct encoding and content-type metadata:

Or, you could look at it this way (notice the byte-order-mark: U+FEFF):

C:\\MyDocuments\\Sources\\Php Data Layer>head -1 diff.html | od -t x1z
0000000 fe ff 00 3c 00 21 00 44 00 4f 00 43 00 54 00 59  >...<.!.D.O.C.T.Y<
0000020 00 50 00 45 00 20 00 48 00 54 00 4d 00 4c 00 20  >.P.E. .H.T.M.L. <
0000040 00 50 00 55 00 42 00 4c 00 49 00 43 00 20 00 22  >.P.U.B.L.I.C. ."<
0000060 00 2d 00 2f 00 2f 00 57 00 33 00 43 00 2f 00 2f  >.-././.W.3.C././<
0000100 00 44 00 54 00 44 00 20 00 48 00 54 00 4d 00 4c  >.D.T.D. .H.T.M.L<
0000120 00 20 00 34 00 2e 00 30 00 31 00 20 00 54 00 72  >. .4...0.1. .T.r<
0000140 00 61 00 6e 00 73 00 69 00 74 00 69 00 6f 00 6e  >.a.n.s.i.t.i.o.n<
0000160 00 61 00 6c 00 2f 00 2f 00 45 00 4e 00 22 00 20  >.a.l././.E.N.". <
0000200 00 22 00 68 00 74 00 74 00 70 00 3a 00 2f 00 2f  >.".h.t.t.p.:././<
0000220 00 77 00 77 00 77 00 2e 00 77 00 33 00 2e 00 6f  >.w.w.w...w.3...o<
0000240 00 72 00 67 00 2f 00 54 00 52 00 2f 00 68 00 74  >.r.g./.T.R./.h.t<
0000260 00 6d 00 6c 00 34 00 2f 00 6c 00 6f 00 6f 00 73  >.m.l.4./.l.o.o.s<
0000300 00 65 00 2e 00 64 00 74 00 64 00 22 00 3e 00 0d  >.e...d.t.d.".>..<
0000320 00 0a   

Looking at the release history of the product, the release 7.x series seems to have had a strong focus on support for international encodings. It sure looks like they did it right. On a side note, remember this illustration from above?

I cheated a little bit: those are actually Unicode “fullwidth” characters used when typesetting mixed Latin and CJK text. This has been an “internationalized” review from the very start!

I didn't explore the Java API for this review. I can document that it exists, and that it's very complete. It's called guiffy.inside, and it includes all the functions of all of the different flavors of the product, both GUI and command-line. It also includes a “hook” mechanism for modifying the behavior of the existing application.

On the command-line side, there are API equivalents for the jiff and suremerge commands so that you can create a windowless compare/merge subsystem inside your own programs. Also, there's a separate API for the HTML report generator.

There are two interfaces for GUI products. The first, called a Frame, essentially pops up the Guiffy application window, menus, dialog boxes, and all. The second, called a Panel, lets you put the Guiffy compare/merge screen inside your application's window. There's no menu, and no toolbars, in the Panel version: you get tight integration with your app, but you have to write the supporting code to pick up filenames and encodings and such.

Finally, there's a hook mechanism so that you can detect the merge result on exit and trigger some behavior. It seems Guiffy is just about as easy as can be to integrate with another application, like a CM tool or a build script or a continuous integration driver. Because this is all in Java, you can build it into an applet running on a web page. Make it a signed applet and your users can do compare and merge operations against their desktop, and you won't even have to install the product on their machines. (You should probably call and ask about licensing, though.)

Guiffy support is just amazingly responsive!

I started this review by visiting the website (http://www.guiffy.com) and downloading the demo version, along with the sample scenarios for compare & merge. When I asked questions by e-mail, I was amazed to get responses at four o'clock in the morning. I was happy to find they were knowledgeable technical answers from someone who could understand what tasks I wanted to do, and how they should work. I also got responses in the afternoon and evening. If anyone in Missouri ever sleeps, you couldn't prove it by me.

SureMerge offers two different modes for grouping changes together. You can choose to see more blocks of changed text, with small numbers of lines, or you can permit grouping of changes into a smaller number of individually bigger blocks. I was unable to detect a difference in the modestly sized files I used for testing purposes.

For my purposes, the accuracy of the tool is 'pinpoint.' Changes are identified down to the individual characters that differ. It doesn't get any better than that.

SureMerge is a set of Java applications with a shell or Windows executable front-end. I was a little nervous about this, after having a bad time starting up Eclipse. SureMerge is definitely not Eclipse: it starts up just fine. Likewise, doing compares is quick even for large(-ish) files. I used some international dictionary files to test both large file operations and international character set support. It takes Guiffy about 15 seconds to re-compare two versions of a 1.7MB Russian dictionary on my two-year-old laptop. Very nice!

For this test, I wrote a perl script to randomly “mutate” about one percent of the lines: delete or move the line, or insert or transpose characters:

The help documentation includes notes for comparing large files when the files have large blocks of changes in them. The change is simply to let SureMerge allocate more memory to work in: everything else is taken care of. I guess that change is required if the files are more different than they are similar, because my files were way over the threshold for needing more memory, yet guiffy worked just fine out of the box.

SureMerge is a tool with some complex features. Overall, the interface is very smooth and self-explanatory. Most advanced operations are explained well by the surrounding menus and dialog box text, with no need to refer to the online help.

That said, I have some complaints. (I'll bet you didn't see that coming.)

• First is support for drag & drop. I'm using a modern JRE (1.5), and yet the drag & drop is all but unusable: the drop targets are the top and bottom row of pixels of the file name combo boxes on the file open dialog.

As I understand it from talking to the author, this is a defect in the Java UI libraries. That doesn't excuse it at the product level: a one-pixel drop target is not a drop target. As clunky as it may be, Guiffy needs to make this work—either code their own GUI widgets (blech!) or add an ugly “Drop Here” box (blech!).

• Second, integrating guiffy with Windows Explorer is documented in a Tech Note in the on-line help. I believe the installer should perform the simple steps automatically on installation.

• Finally, the dialog box for choosing character encodings needs work. Presently, the encodings are specified as text entry boxes: you type in the encodings. But since the list of supported encodings is known in advance, this should be a drop-down list or a combo list. It was frustrating to be told I needed an additional file:

It was even more frustrating to realize that the encoding I wanted was supported, just spelled differently ('koi8'). I'm sure that if you spend all day every day in a particular encoding you know how to spell it. But if you have to deal with different encodings on a regular basis, a pull-down list is your friend.

Overall, the product itself is very easy to use and install. But it could be better integrated with the desktop, and the user interface needs to be a little bit more helpful.

SureMerge gets the job done. It gets the job done well. The tool is fast, it is accurate, and it is easy to use. Using the file-encoding feature lets you view changes at both the 'byte' level and at the 'code point' level. You can see that a character has changed, or you can switch views and see just exactly how the binary expression of that character has changed. For anyone dealing with i18n issues this is a godsend.

Included in the on-line help are instructions for integrating SureMerge with eight different CM tools. For PVCS, Guiffy even includes a specially built executable that replaces the pvcsmerge program for seamless integration. (Support for the other tools is probably just as seamless, but they offer configuration options to let you set the name of the merge tool so Guiffy doesn't have to ship eight different executables.)

The addition of batch reporting facilities and HTML report generation makes SureMerge a valuable tool for a whole team, not just individual developers. Now change sets and impact statements can be automatically displayed from an intranet dashboard. Continuous integration and nightly build scripts can be extended to produce clear, detailed, attractive code change summaries. Sweet!

Single-user licenses for SureMerge are USD $75. Price breaks occur at 3 users (3/$150) and again at 36 users. SureMerge is a good value for managers or team leads looking to provide a standard tool to their developers.

SureMerge is a solid, capable tool, as you would expect from a 7.2 release. It performs well and does a great job helping developers, build managers, team leads, and other players in the development cycle understand exactly what is going on with the code. The GUI itself is easy to use and is available in several languages. The tool is obviously growing, with international encoding support and HTML report generations being the most recent major features added. Guiffy, the company, is personified by owner Bill Ritcher: quick to respond, helpful, and willing to work with you to help get over any problems. I like the tool, and you will, too.