Did you get the newsletter?

Posted by Jeremy Fri, 28 Dec 2007 09:28:00 GMT

SourceGear recently sent out the first of its quarterly newsletters. Since this is the first mass mailing we’ve done in a long time, we keyed it off of the email addresses we had in our sales system. Since in some companies the person buying Vault may not be the person using Vault, it’s worth it to mention the newsletter here, to see if any developers and managers missed out on it. You can read the first newsletter here.

Some guidelines we tried to follow:

  1. The newsletter should not be too frequent. Quarterly is enough.
  2. The newsletter should be informative. The first one has a feature on the new Image Paste and Edit feature that’s in the Fortress Eclipse client in beta 1, and coming for the Visual Studio client and the standalone Windows GUI for beta 2.
  3. Communication is a two-way street. We want to hear from customers, and have included a poll in the newsletter, as well as a direct email address for the newsletter’s editor.

To sign up to get future newsletters, go to: https://csp.sourcegear.com/preferences.aspx. This will require you to sign in with your email address to our Customer Service Portal, but once that dance is done, you will get fresh information pushed to you every three months or so.

no comments

Beta Secret #2 - Web Diff

Posted by Jeremy Wed, 12 Dec 2007 13:07:00 GMT

One of the goals of the 4.1 development cycle was to begin the process of updating our web client to make it as cool as the web sites that some of our customers are creating as they use Vault and Fortress.

I’ve already blogged about the Tag Clouds, which brought along quite a bit of Dynamic HTML (yes, we’re about 8 years late to the DHTML party). The feature I want to highlight for this post is the new Web Diff page in the Source Control section of the web client.

You can view an example web diff here. Remember to log in using the guest1 through guest9 username with the username as the password. There are quite a few awesome features to talk about.

  • Unified diff. This is the first place in Vault where we’ve shown a Unified Diff. All our other diff tools were concerned with migrating changes between the two versions, so unified was never a good option. Now that it’s in web diff, I love it. You can still load up the traditional side-by-side, but be prepared to scroll.
  • Line Wrapping. This mode will wrap long lines, to reduce scrolling.
  • Lines of context. Select the lines of context also. Please note that the three settings above are saved in a cookie, so that you can always get the view of differences that you want.
  • Version Selection. You can also quickly select the versions of the file to diff from the dropdown.
  • Transaction Details. To get the details for the transaction that created a particular version, you can click the Details link.

All of this was done by Jeff Hostetler, the same developer who brought us the wonderful SourceGear DiffMerge app, which is currently available free of charge.

With all of the changes modernizing the web client, we’re all excited about the release of .Net Framework 3.5, which includes built-in AJAX support. Expect an even richer web client experience in the future.


Beta Secret #1 - RSS and Saved Queries

Posted by Jeremy Tue, 04 Dec 2007 08:27:00 GMT

For those of you trying the Fortress 1.1 server beta, here’s something that we added that is pretty cool. We publicly stated in the release notes that 1.1 has support for Saved Queries in the web client. What we haven’t mentioned yet is that you can also use saved queries in the RSS feeds.

To set up an RSS feed for a Fortress server, subscribe to a URL that looks like this (please pardon the wrapped URL):

http://FORTRESSSERVER/Fortress/Feeds/BugTrackingFeed.aspx?user=USERNAME &password=PASSWORD&pid=PROJECTID&qname=SAVEDQUERYNAME

I’ve set up an example feed for the guest7 account over on fortressbeta.sourcegear.com. Here’s the URL if you would like to subscribe to it, to see how it works in your aggregator.

Sample RSS Feed


Vault 4.1 beta 1 is released

Posted by Jeremy Mon, 26 Nov 2007 16:48:00 GMT

During the development of the 4.1 Vault release and the 1.1 release of Fortress, we’re trying to find new ways of keeping our customers informed about the changes that are coming. The Vault Blog the first step on improving our communication. The next step of that effort is more beta periods to give users a chance to offer input. We’re happy to announce the availability of the first of two planned beta periods for the 4.1/1.1 release. To ensure that more people can try this beta, the client portion of the beta will be able to connect to a 4.0/1.0 server. If you have questions, or just want to find out what people think of the beta, you can do so at our support forum. To see the web client portion of Fortress 1.1 in action, go to http://fortressbeta.sourcegear.com.

Here are some highlights of the new Beta:

Fortress Changes

  • Tag Clouds. This new feature will help you to track work items by marking related bugs with keywords. For example, it would be possible to mark all bugs where words are misspelled with the “grammar” tag, regardless of which part of your system they occur. There are also views that help you look at a work item query and see at a glance, the relative weights of Assignees, Priorities, Categories, etc… For more details on this new feature, see: http://vaultblog.sourcegear.com/articles/2007/08/30/tag-clouds
  • New Query Page / Saved Queries. The saved query feature, which was formerly only available in the Fortress Visual Studio client is now in the Web Client. Also, there is a new Work Item Query page.
  • Paste and Edit images on the clipboard. This beta will introduce a new streamlined way to put images into work items. For this beta, this feature will only be available in the Fortress Eclipse plugin, but support for the Visual Studio plugin and the Windows GUI client will be added in the future.

Visual Studio Changes

  • Visual Studio 2008 Support. This beta is the first release to support Visual Studio 2008.
  • Legacy Options. Many users requested that some of the source control options that were supported in the 2003 compatible client be implemented in the 2005 client. The first two options supported are: Get Latest when a solution is opened and Check In when a solution is closed.

Java Clients

  • Ant Tasks. This beta introduces support for Ant tasks.
  • Java CLC. For users on non-Windows platforms, there is now a Java based command line client.


Vault 4.0.5 is released

Posted by Jeremy Thu, 25 Oct 2007 16:54:00 GMT

We’re very happy to announce that Vault 4.0.5 is released now. Thanks to everyone who downloaded the beta. 4.0.5 is the most significant maintenance release for 4.0, and we hope that all of our users will appreciate the hard work that went into it.

4.0.5 is finally the release where we support having bound projects in an unbound solution in the Visual Studio 2005 client, which is something that everyone’s been requesting since hours after the 4.0.0 release. You can get to this new functionality by using the File->Change Vault Bindings… menu item. The new Change Bindings dialog will immediately look somewhat familiar to anyone who was used to the old MSSCCI Change Source Control Bindings dialog.

The other big feature in the 4.0.5 Visual Studio 2005 client is the elimination of the need to perform two get operations when someone else has added files to a project. It’s a deceptively simple feature that turned out to be quite hard to get working.

As an aside, expect some announcement of the first of two scheduled 4.1 beta periods in the next month. We’re about to deploy the full UI for tag clouds on our internal dogfood server, and I’m very much looking forward to using tags to drill down into our bugs.

no comments

DiffMerge 3.1 is released

Posted by Jeremy Thu, 11 Oct 2007 09:16:00 GMT

We’ve now released version 3.1 of SourceGear DiffMerge. The important changes since the beta are:

  1. We now support the “mark the first file, then browse to a different folder, select a second file and diff it against the first” workflow that was requested in the beta period.

  2. There was a crash reported when clicking in the window while the files were still loading.

You can get the 3.1 release at our DiffMerge downloads page.

Thanks for your continued support of our products, and giving us the feedback we need to make high-quality dev tools.

no comments

4.0.5 beta now available

Posted by Jeremy Tue, 09 Oct 2007 11:42:00 GMT

Vault 4.0.5 has been two months in the making, which makes it the largest maintenance release yet for 4.0. There are several new features that we are sure that users will appreciate. We’ve tested it thoroughly, but would appreciate any feedback from users on the new features that we’ve added. You can download the beta at: http://www.sourcegear.com/vault/downloads.html

The largest changes are to the Visual Studio 2005 client:

  1. A new Change Bindings dialog, which will allow users to configure an unbound solution with bound projects. This also moves the online/offline and binding operations from the context menu.

  2. The Double-Get fix, which means that no longer will users be required to perform two get operations to get files that have been added to a project or solution.

  3. The bin directory should no longer be added to source control for web site projects.

For the full release notes of the beta, see http://www.sourcegear.com/vault/releases/4.0.5b.html

no comments

SourceGear's Tag List

Posted by Jeremy Mon, 24 Sep 2007 09:27:00 GMT

In the comments for the post on Tag Clouds, I mentioned one of my goals was to actually provide the “standard” list of tags we use internally. These are tags that we use to imply priority, so that everyone on the team can look at a bug, see which tags apply to it and immediately know what priority the bug should be. I should also reiterate that a bug which was assigned a lower priority because of a tag like Trivial or Grammar will still get fixed more quickly than some higher-priority bugs. Tags are a labeling mechanism that makes them easier to find.


  • PO
    • Blocker: This bug is preventing others within the company from fixing or testing on other items. The item has a time-critical context that supersedes the perceived priority.
  • P1
    • Data Corruption: Any error, whether GUI or API, where server data is or can be corrupted.
    • Broken Beyond Repair: Product feature does not work. No workaround exists
    • Server Crash: Server crash of any kind.
    • Obvious Client Crash: Client crash that is both reproducible and frequent
    • Legal: Errors in wording or use of copyrighted material that presents legal ramifications.
    • First Impression: Issues occurring in the first hour of use that negatively affect sales.
  • P2
    • Broken Causing Pain: Product feature is impacted, but the existing workaround requires extra steps or is impractical.
    • Odd Client Crash: Client crash that is either reproducible or frequent
    • Performance: Performance issues that are common.
    • Support Headache: Small or medium impact, but creates substantial confusion and high support load.
    • Fairly Common: Particular aspect of subfeature not working as designed, and likely to be seen by several customers.
  • P3
    • Broken with Workaround: Product functionality is impacted, but a viable workaround exists.
    • Embarrassing: Impact is small or negligible, but visibility presents poor company image.
    • Broken on Goofy System: Usability not present on certain older systems or non-prevalent machine setups.
    • Well Contained: Particular aspect of sub-feature not working as designed.
    • Odd Performance: Performance issues due to large or odd setups.
    • Not User Friendly: Incorrect error messages likely to produce some support load.
    • Unlikely, but Severe: Infrequent order of steps causes serious error.
  • P4
    • Bug on Goofy System: Usability reduced on certain older systems or non-prevalent machines setups.
    • Hand-Holding: Product functionality doesn’t match user expectations, needs better alerts or help.
    • Grammar: Incorrect or awkward titles or wordings in dialogs.
    • Trivial: Feature impact is small or negligible, and not embarrassing.
    • Phase of the Moon: Infrequent set up steps causes small error.

It has benefited us to make the priority guidelines for feature separate from bugs. In fact there have been times when trying and failing to find the appropriate bug-tags to put on an incoming item has caused me to think “That’s no bug… That’s a feature request!”


  • FO
    • Blocker: This feature is preventing others within the company from fixing or testing on other items. The item has a time-critical context that supersedes the perceived priority.
  • F1
    • Very Popular: Many people would be positively and substantially impacted by this addition. We have so many requests for this; we need a really good reason why NOT to add it.
    • Internal Consistency: This feature would allow different clients to work the same as their counterparts.
    • Preventative: The program works in a reasonable manner, yet certain bizarre work habits or program interactions will cause problems. This feature will prevent those from occurring.
  • F2
    • Extra Steps: Not having the feature forces the user to stop and figure out how to do what he intended to do by navigating through extra steps
    • Exceeds Expectations: This feature’s existence pleasantly surprises the user, creating customer loyalty.
    • First Impression: Feature additions that positively impact the first hour of use and therefore raise sales.
    • Administration: This feature helps the IT guys maintain Vault with less hassle.
    • Worthy: Many people would be positively or substantially impacted by this addition.
  • F3
    • Graceful: Functionality is not significant, but visibility presents good company image.
    • User Friendly: Better help or error messages likely to reduce customer annoyance or support load.
    • Performance: Adding this feature will improve program speed.
    • VSSConsistency: It needs to work like VSS does.
  • F4
    • Options: Users would like another way to manage his workflow.
    • Useful: Small featurette provides utility for a subset of customers.
    • Odd Configurations: Usability requested for certain odd program interactions, or unsupported systems.
  • F5
    • Diversion: It’s a reasonable request, but it doesn’t quite fit in with our company direction.
    • Misguided: A user is asking for something that ultimately would be a poor choice.
    • Behemoth: While this is a reasonable request, implementing it would take excessive work and have consequences that will spiral out of control in terms of bugs.

no comments

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.


Tag Clouds

Posted by Jeremy Thu, 30 Aug 2007 15: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.


Older posts: 1 ... 3 4 5 6