Richards Merge Tool
Richards Merge ToolThere have to be MergeTools, 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:
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 which happens 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.
-- DanMuller
I'm fairly certain I've used a merge tool (probably EclipseIde, but could be WinDiff? or DirDiff?) 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/)
EditText of this page
(last edited March 28, 2006)
or FindPage with title or text search