There have to be MergeTool
s, right? Unfortunately, I've never heard of any standalones so I'll design one from scratch.
The merge tool has two areas, a left one and a right one like MidnightCommander
. Both areas are of equal size and there's no way to change that.
Each area takes one file. When an area hasn't had any files dropped down on it, it's taken to be empty.
The differator runs continually and there's no need for an explicit comparison command. Every time a file in either area is changed or loaded, a new comparison is run. The differator runs in case sensitive text-mode
and there are no other options.
At the top of the merge tool, above the two areas, there are numeric
results for the total number of non-whitespace
- lines added in the left area
- lines changed in the left area / in the right area
- lines deleted in the left area
The first is above the left area, the second is above the middle, the third is above the right area. Below each of the above numeric results, there is a row of numeric results for whitespace.
The merge tool uses colour highlighting; one colour for additions, another for deletions, and the combination of both colours for changes. The highlighting is done in place
and missing text is where it would be if it wasn't missing, just highlighted. There's no need for any useless and cryptic 943c23 references, whatever they might mean.
The two areas share one
scroll bar because scrolling is simultaneous in both areas. Both areas are always synchronized together, there is no way to desynchronize them. When an area contains a shorter change than the other area and scrolling has come to the end of that change, the shorter area will pause scrolling to wait for the longer one to catch up.
The unique scroll bar isn't in the middle but on the right. There is nothing in the middle to block the left area from the right. At any time, the user can drag and drop a change, deletion or addition in toto
from one area to the other area. They do not need to select any text and they don't need to be accurate in their target. The user picks up a change
to present itself as text (and not a button or something equally stupid) and just has to drop it to the other area to apply it.
When a user has moved a change from one area to the next, the file is saved and the differator is run over the new contents. IOW, the change disappears from view entirely.
If the target area's file is read-only then the cursor doesn't change to indicate that something can be dropped onto it. There are no stupid and annoying beeps, there are no error dialogs, there are no error messages of any kind. The user can see for themselves that nothing happened. Conversely, upon success there are no nifty keen noises since the user can see for themselves that something happened. The merge tool isn't annoying or flashy.
The merge tool operates on MERGE files. To create a new merge, you right click on some empty space, select New and Merge. The merge file contains all "temporary" data of each merge run including but not limited to the names and locations of the files to be merged and the merges that have been performed on both files.
There are no save buttons, no save as buttons, no open file buttons and no menu bar. These features don't exist. The merge tool saves all files after each operation and before closing.
The merge file is logged so that a computer crash in the middle of a merge will not leave the files in an inconsistent state. The fact that such a crash will likely destroy any file being written is ignored; a versioned operating system is assumed.
There is an infinite undo CactusStack
. The top-most contents of this stack are constantly visible at the bottom of the merge tool. By contents we mean "addition to <name of file>" or "deletion to <name of other file>" assuming the names are different, LHS and RHS if they are not. The cactus stack is part of the "temporary" information of a merge run and so stored in the merge file.
A user can right click on a merge and has the option of undoing it or everything after it. Any merges that are undone are removed from the main branch (whatever branch of the catcus stack the user is working in) and moved to a new branch. Consecutive merge undoes are moved to the same new branch. A user can also right click on a merge off of the main branch to merge it with the main branch. A user may finally switch to a different branch of the cactus stack.
When a user navigates the cactus stack, the merge tool scrolls (at human normal speed, not freakishly fast) to the location of the merge. When the user is done manipulating merges, they can go back to the top of the cactus stack, where their last free location has been kept in a dummy merge, described perhaps as "current merge".
I'm pretty happy with this design since it validates and entrenches my position on AutomaticVsManualPlacement
against the manual placement of objects. You don't need to place objects side by side even to compare them, the comparison is its own object. Not that I was worried but I did wonder. Well, not really. Oh, hell, it's just a good design!
See also MergeTool
Why would anyone ever use this tool? How often do documents diverge in such a way that the semantics are similar enough to make this tool useful? It seems to me like the exception not the rule. The only places I could think of would be poetry and derivatives. -- DaveFayram
What Richard describes above is only partly a merge tool, it's more like an interesting UI for what sounds like a vague sketch of a pretty pedestrian VersionControlSystem
. Version control is used most often for program source code, but it's also used pretty commonly for text documents. The 'diff' algorithms involved don't care about semantics, they just look for similar chunks of text -- usually chunks of lines, more specifically. How good a job they do varies with the algorithm, content, and the eye of the beholder.
Richard's design is pretty bare-bones, IMO, and would be inadequate for a lot of real-world scenarios. For instance, the requirement to always keep the two views synchronized is quite unrealistic when the files differ due to blocks being moved over long distances. (What does 'synchronized' mean in such instances? Synchronized according to which text -- the text moved, or the surrounding text not moved?) It would be very annoyingly restrictive in such cases. His disparaging comment about "cryptic 943c23 references" refers to typical output from traditional UNIX diff programs, which predate graphical interfaces by decades. The other tools which were mentioned (moved to MergeTools?
) are more modern and more interactive, and do in fact provide interfaces that are somewhat closer to what Richard describes, to varying degrees.
I'm fairly certain I've used a merge tool (probably EclipseIde
, but could be WinDiff?
) that had only a single scroll bar and automatically kept the views synchronized. It was a huge usability improvement over tools with separate scrollbars. It dealt with block movement by only scrolling the pane with inserted text until the two panes were synchronized again. In every case I encountered, this was just what I wanted.
Oh, and it had just about every other feature Richard mentioned too, except for separate MERGE files and unlimited undo (it was a frontend for CVS, though, so you've basically got unlimited undo anyway). I think that having separate MERGE files is a mistake, anyway: I'm often more interested in viewing differences than fixing them. -- JonathanTang
it sounds quite like linCVS which certainly has a nice diff output (cant remember if merge but probably) with colour coding and a single central scroll bar which is also colour coded so you can see where all edits in document are in one go (sorry that description isnt very good here is an url http://www.lincvs.org/
- Viewing changes in the history of a single document is a completely different application. You no longer need multiple panes at all since you're no longer moving anything between them. It's better to have a single pane that shows multiple levels of changes somehow. Colour is only one option. Another option is to have changed paragraphs in the later version shown in a pane to the right but with recurring paragraphs suppressed. But since you've got an ordered history, you need to ensure that before and after are presented to the user. And you've also got to present the history of the file as a continuum which the user can sample from. These make for very different requirements.
Synchronizing usually is what you want; I should have emphasized that requiring to always
be synchronized is potentially painful. I think you might be describing WinDiff?
, but it's been a while since I used it. More recently, I use ediff in XEmacs. There, navigation is not forcibly synchronized, but you usually navigate by moving from one block to the next, and the two panes are
kept synchronized when you move this way. It's easy to copy each individual change block to or from each version. (Of course, there are lots of things about ediff/Emacs that would make it prototypically 'crap' to RK.) The merge sounds like the information that a VCS usually stores internally to describe changes between versions; hence my comment about version control. But I could be misinterpreting RK's intent. -- DanMuller
- Merge files are a design artifact to make everything nicely direct-manipulated and to provide reversible operations.
Apple's Dev tools come with a truly outstanding visual diff/merge tool that solves the long-block-displacement problem by using a bezier curve outline around differing regions, linking them across the boundary between windows. Not only is this approach beautiful (they get a nice smooth outline of a distinct color) but it makes it clear which differences associate where. The scroll synchronization problem goes away in this scenario. In fact, I'd say it meets almost every requirement that this tool has, and then some. -- DaveFayram
- Wish I could see it.
- Apple computers come with the dev kit standard (and free as in gratis). Buy a mac mini or something and try it. Better yet, get a swell G5 iMac and give it a whirl. Those PPC970fx processors are ungodly fast when you use the builtin vector engine.