Posted by Jeremy
Mon, 10 Sep 2007 14: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
Posted by Jeremy
Thu, 30 Aug 2007 20:23:00 GMT
In our work item tracking system, we have
over 1800 open items, ranging from bugs
to feature requests from our customers. It’s a nearly impossible task to go through all of them quickly to find the set of bugs which should be fixed in the next release of Vault. We try to alleviate the strain by making sure that bugs have an appropriate priority and category, to help us find the bugs that are important and the bugs that are near the code we’re fixing anyway. The problem with category and priority is that they are too rigid to be truly helpful. Only administrators can create new priorities and new categories. That’s why we’re adding a tagging mechanism to Fortress 1.1, so that all users can help organize the bug database. So that we’re all on the same page, Wikipedia defines a tag as a keyword associated with a piece of information. In our use, the piece of information is a work item. If you want to skip right to your chance to play with a mockup that we’ve done, go here.
An overview of tags
The big picture view of tags in Fortress is that a list of keywords can be associated with a bug. If you have a bug with the description “Client throws exception on startup when using Microsoft .Net Framework v3.0 on Vista”, a reasonable set of tags to apply would be “Crash .Net30 Vista”.
Problems with Priority
The problem with priority is that it doesn’t tell you why the bug got its priority. Internally, we’ve developed a list of common tags that imply a priority. For example, any of the tags DataCorruption FirstImpression and BrokenBeyondRepair imply that the bug should be prioritized with the highest priority. Similarly, the tags PhaseOfTheMoon and Grammar imply that the bug should be given the lowest priority, since they don’t impact the product significantly.
I mentioned the Grammar tag specifically, because it is a case where the priority is low for the right reason, but we still want to easily find all of these Grammar bugs in the database, so that they can be fixed. Another reason that Grammar is interesting is that a Grammar bug can happen in any aspect of the product, so this tag will be applied across many different categories.
Tag Clouds
The common thing to do with tags, once you’ve applied them to all of your bugs, would be to view a Tag Cloud for your open bugs. Once again, turning to Wikipedia, the definition of a tag cloud is a visual depiction of a group of tags, which are ordered alphabetically, but more frequent tags are represented as larger than others.
Here’s what an example tag cloud might look like:
You can see that the Performance tag appears largest, because it is the most frequently applied tag.
Extending Tag Clouds
One way in which we’re going above and beyond the usual Tag Cloud implementation is that we’re adding the ability to see a tag cloud for query results. This means that when you search for your open bugs for the current milestone, you can see a tag cloud that represents only the bugs returned in the query. This is a huge benefit when you’re trying to find bugs in your system.
The second way that we’re extending tag clouds is the ability to see a cloud of the other attributes on a bug. For example, an assignee cloud might look like this:
or a milestone cloud might look like this:
Give us your feedback
First, I invite everyone to give our Tag Cloud mockup a try. This is an implementation of the web client interface that does not connect to an actual database. We wanted to get a handle on the User Interface issues and get feedback from customers before we began work in earnest. I encourage you all to post your impressions/requests in the comments on this blog post. We want to incorporate the best ideas that you have.
5 comments
Posted by Jeremy
Wed, 08 Aug 2007 16:47:00 GMT
Welcome to all of you who are interested in following the progress of the next release of Vault and Fortress. Our next planned release will be Vault 4.1/Fortress 1.1, and will include new features, as well as many bug fixes. The goal of this blog is to include customers in the discussions that we have every day regarding how features should work.
Here are the kinds of topics you can expect to be discussed here:
Previews of upcoming features. With these posts, we hope to show our designs for upcoming changes to you, our customers, early (sometimes before we’ve even started coding them). This will allow us to incorporate your feedback before it’s too late to change the design.
Progress reports. We plan on having two beta periods for the next release of Vault, and we want to keep customers in the loop with regards to trying out the latest changes and keeping up to date on the scheduling of the betas and the final release.
Here at the start, I should give fair warning, this blog will not update as frequently as might be expected from a blog, but the updates should be high in content when they occur. I would recommend that everyone subscribe to the RSS feed early to automatically keep up with changes.
As always, thank you for following the progress that we’re making.
no comments
