DiffMerge 3.1 beta

Posted by Jeremy Mon, 10 Sep 2007 09:49:00 GMT

We’ve been hard at work on a new version of DiffMerge, which will address many of the issues that people have brought up with our initial release. Here’s a list of the big changes:

  • Windows Shell Extension: Added integration with Windows Shell/Explorer. A ‘Compare with DiffMerge’ menu item was added to the Windows Explorer right-mouse context menu for files and folders. This feature can be enabled/disabled from the Options dialog.

  • Changed Installer: The .MSI installer is now generated using Advanced Installer. This fixed several installation-related problems, especially on Vista. Administrative privileges are still required for installation, but under Vista, the installer will use the privilege elevation mechanism so that you don’t need to be logged in as an administrator to start the installation. If you do not have administrator access to your machine, please use the .ZIP package.

  • Items Placed on Clipboard Remain after Exit: We no longer clear the clipboard when DiffMerge exits.

  • Fixed Various Crashes: Fixed various crashes when windows were closed using the ESC key while the mouse was captured. Fixed crash after auto-merge. Fixed various crashes on Mac OS X when comparing files or folders whose pathnames contained special characters.

  • Added Batch Output Option: Added the ability to use DiffMerge as a command line tool and produce traditional or Unified differences of two files to an output file rather than opening a window. The output is compatible with GNU diff(1) and patch(1).

  • Added ‘Save As’ Feature: Added File|Save As… feature to editable windows. The editable file is written to the new pathname and the window titles are updated. Changed behavior of ‘/result:pathname’ to behave like ‘Save As’ (and re-title windows) whenever possible.

  • Added Force-Write Feature: Added code to attempt (after prompting) to override the on-disk file permissions when trying to write to a file that is read-only.

  • Added Backward Searching and Wrap Around to Find Dialog

  • Scrolling from Glance Window: Clicking and dragging in the glance window on the left now cause the file windows to scroll; previously we only scrolled the file windows on clicks.

You can download this new version at our DiffMerge downloads page and read the full release notes.

If you try this new beta, give us your feedback by replying to this post, or over on our support forum. We hope to officially release DiffMerge 3.1 in the next few weeks.

21 comments

Comments

  1. Abby said 1 day later:
    The shell extension is a great improvement, but it would be even better if you could use it to also select the second folder/file to compare. Otherwise, it kind of defeats the purpose of the shell extension in the first place. It's purpose is to use windows explorer to select the file/folder, and to have to then browse for the second file/folder is tedious when you've already been working from explorer. Other than that, DiffMerge is a really crisp, fresh product. Good work.
  2. Tim said 1 day later:
    Finally I feel like it is good enough to back-integrate with Vault, replacing the old default sgdm.exe. However, there are many things I'm still uncomfortable with: 1) The new diffmerge by default came up at an rather small window width on my screen (probably 640 pixels?). I kind of like that it isn't maximized by default, but I need lots of width for side-by side diffing. 2) The default font size is larger than I am used to, which again makes it harder to fit all the needed information on the screen. (Luckily I can customize this easily, but...) 3) In folder diff view, why can't you view files without peers by double-clicking? 4) In folder diff view, there is no way to sort files by 'present in left', 'present in right', 'modified'. 5) In 2-way file diff view, why can I only edit the right-hand file? Sometimes It should sometimes be easier to use 2-way file diff to edit both files until they look the same, than to get a baseline copy, and set up a 3-way merge. 6) The old diffmerge's (1.1) feature of clicking on the edge of the change highlighting block in the middle of the screen to merge the change across to the other side was very cool, but is now gone?! 7) And probably the biggest one: I don't like the default pastel colour scheme, but its too hard to change! The reason I don't like it is that without bright colours (something looking like fluorescent marker highlighting), the changes don't leap out from the background and catch my eye. Also, because of all the intra-line colouring and text colouring needing to colour coordinate with the background colouring, its a LOT of work to make it look good. A compromise solution to changing the default is to provide colour /schemes/ to choose from (especially something based on that retro source gear diff merge version 1.1?), which could reduce the work needed to get a scheme I think looks good.
  3. Tim said 1 day later:
    8) For smallish files, there are large regions of the glance window (near top and bottom) where clicking and dragging doesn't have any effect on the current scroll position. This happens because e.g. you're already at the top, and you're trying to drag the view down, but you're doing it too close to the top of the glance window. There is also no easy way to see the magic place past which you have to click/drag to get scrolling to start happening.
  4. Tim said 1 day later:
    9) No distinction in folder view between equal folders and non-equal folders?!
  5. Tim said 1 day later:
    -9) Scratch that last one, I think I misunderstood how the show folders is working.
  6. Matt said 2 days later:
    From my perspective, the purpose of a shell extension is to allow me to exclusively use the shell to quickly execute a diff. In the current implementation I can't do that. Here's the use case: In explorer, I need to be able to right click on a file or folder and tell DiffMerge to remember that file for a future comparison. Then I right click on another file or folder and tell DiffMerge to compare it with the previously selected file/folder.
  7. jeffhostetler said 2 days later:
    Thanks for the comments. When I did the shell extension, I made it so that it allows you to select one or two files or folders and then open DiffMerge on them. We thought that would be an easier usage model than one where you had to first "mark" one file and then do a "compare with marked". That is, one click instead of two and one consistent menu item instead of several that change depending on the state of things. But yes, the simpler model doesn't let you select one file in one folder and a second file in another folder. And yes, it is a *pain* to have to browse for the second one from the File Open dialog. I'll add this before we ship 3.1.
  8. Jeremy said 2 days later:
    Abby, If you have two explorer windows open you should be able to open DiffMerge with the context menu in the first explorer window, then drag the file from the second explorer into the text box in the open dialog. I understand that I'm giving a workaround, and not really solving what you want. We're looking at ways to do a "Remember this as the first file in a diff" entry in the context menu, as you and Matt have suggested. Thanks for the feedback!
  9. Jeremy said 2 days later:
    Tim, The one that I feel we can probably help in some way is #7, the desire for more color schemes. I very much understand your desire to avoid the hassle of changing every single setting. Because colors are set in the registry, it's likely that we can implement a color scheme and then send you a .reg file to run that would load a new scheme. In fact, I think that it would be great to have a thread on the support forum to allow people to share their color schemes. What do you think?
  10. jeffhostetler said 2 days later:
    Tim, for item #8: The "file at a glance" window on the left shows the changes throughout the entire file. The black bars show the portion currently on screen. When you click and/or drag in the window, it tries to recenter the file windows around the corresponding line. The thought being that you want to click/warp directly to the changes. For short files, the black bars are not that useful because such a large portion of the files are always on screen. But to answer your question, the mid-point of the black bars should be the place where clicking or dragging starts to cause the windows to scroll. That is, when you are scrolled to the top of the window, clicking above the mid-point doesn't do anything because it can't center the corresponding line. And clicking below the mid-point causes scrolling and the black bars to shift and be centered at the new mouse position. Hope this helps and sorry for the confusion.
  11. Chris said 3 days later:
    I would like to second Tim's #5. Sometimes it is quite inconvenient to only be able to merge changes from "old" to "new". Often the situation I have is that I've gone ahead with a large number of changes to a file, and it ends up that only some of them will be necessary, so what I want to do is merge only the changes I want to keep from the "new" version into the "old" version to create a new "new" version. I understand I can use the 3-way feature, but that requires the extra step of copying the file, which I already have a safe copy of in my source repository. Or I can reverse the files, but then it's easy to forget which one is which, since the "old" and "new" labels don't apply in the same way anymore.
  12. jeffhostetler said 4 days later:

    WRT Chris and Tim's suggestion:

    Yes, we've had several requests for being able to edit both sides. (And frankly, there are times that I would like to be able to too.)

    We had it in the original version and didn't put it in this version because some users found it confusing (especially in a 3-way merge).

    By having only one panel editable, we were hoping to present the paradigm of editing ONE file with one (or two) additional files beside it for reference. We were hoping that this new focus would eliminate the confusion.

    I'll add your votes to the tally. I can't promise anything at this time, but it will get discussed as we plan the next release.

  13. jeffhostetler said 4 days later:

    WRT Tim's #3 and #4 (folder diff suggestions): these features have been logged.

    Thanks for the suggestions.

  14. jeffhostetler said 4 days later:

    WRT Tim's #6 (clicking on merge blocks in the gutter to apply): since we now display the files vertically aligned (with voids), we don't need the gutter to display linking lines between matching blocks. So I got rid of the gutter. (sorry)

    As an alternative, you can click the mouse on any of the colored lines and you should get a dotted rectangle around it. Then right click and select the first item on the context menu.

    Alternatively, you can use the next-change and apply-change toolbar buttons. These also have ALT+arrow key bindings.

    Hope this helps.

  15. jeffhostetler said 7 days later:
    WRT Tim's #7 on Color Schemes. I've posted a .REG file on the support forum http://support.sourcegear.com/viewtopic.php?p=35395#35395 for a 'classic' color scheme.

    Hope this helps.

  16. Tim said 20 days later:
    "Alternatively, you can use the next-change and apply-change toolbar buttons. These also have ALT+arrow key bindings." Is this just one-way application of differences, not from either side? Also having to deal with the context menu doesn't come close to being able to do it in one click.
  17. jeffhostetler said 21 days later:
    In a 3-way merge: Alt+Right_Arrow applies the change from the left panel into the center panel. Alt+Left Array applies the change from the right panel into the center panel. if you also press Control (or turn on 'automatically advance' in the options dialog), it will advance to the next change after applying the change. Also, Alt+Up_Arrow and Alt+Down_Arrow will jump to the previous/next change.
  18. Mark said 28 days later:
    I've also reported this in the support forum for DiffMerge, but it looks like rulesets aren't applied for directory compares (Folder Diff)? We've modified our C/C++ ruleset to omit lines with Vault keywords, and this appears to work correctly when comparing individual files. When comparing directories, these files are still flagged as being different (our primary culprit is $Header: when having 2 copies in 2 different folders).
  19. jeffhostetler said 28 days later:
    Sorry, but that's by design.

    FolderDiff doesn't run the full diff-engine on when scanning directories. It does a straight memcmp on each pair of files and stops as soon as it finds a difference. This was done for speed. FolderDiff would be very slow if ran everything thru the full diff-engine.

    There are problems with this approach as you point out (and for stuff like EOL chars) where it'd be nice if it did it the other way.

    I'll put in a request to make this an option.

  20. CliveRichardson said 2 months later:
    We make extensive use of 'build automation' tools like FinalBuilder that have built in Vault actions (like checkin, checkout, etc). I recently had a requirement to develop a FinalBuilder 'build project' aimed at SQL Server jobs and this involved comparing the scripted out version of jobs in production with job scripts held in Vault. I had to use Beyond Compare in the end as DiffMerge couldn't effectively be called from FinalBuilder. In the absense of FinalBuilder actions for DiffMerge, a command line or COM interface would have provided a solution. I also write VB.NET and ASP.NET apps using VB to help automate various aspects of the build process and really helps when applications have a good API. Vault has an API of course. Does anyone think it would be worthwhile to have an API for DiffMerge?
  21. jeffhostetler said 2 months later:
    I'm a little confused by your post, DiffMerge does have a command line interface. With the 3.1 release, it also has a batch output feature.

    It sounds like you're asking for a general scripting/automation api. What kind of things/operations are you looking for?

Comments are disabled