Paul Roub

The second beta releases of SourceGear Vault 5 and Fortress 2 are now available: Vault 5b2 is here, Fortress 2b2 is here.

This should be the last preview before the final release of Vault 5 and Fortress 2, so speak now or forever hold your peace (or at least, hold it until the next release).

Jeremy has the details on beta 2. Previously, I'd talked about the updated web interface and the new WebDAV interface; Jeremy dropped hints about the new import tool (now in place, and known as "Handoff") and Shelve.

We should be releasing Beta 2 of Vault 5 and Fortress 2 later today (watch the Development Blog for details). You'll notice pretty quickly that the web interface has been revamped, especially on the work item tracking side; seemed worth a walkthrough of its own.

The Query page is not terribly different; but cleaner and easier to navigate.

Sometimes it's as simple as letting you "roll up" any projects you're not interested in at the moment, keeping your front page cleaner:

Once we start viewing query results, the changes really make themselves known. As always, we aim toward making it easier to find the bug you're after. Hovering over the magnifying glass icon next to any bug in the list gives you a quick summary of that bug, without needing to leave the list and load the whole thing:

We've removed the sidebar, giving more space over to the actual bug information; selection of Customized and Grouped views has moved to the list header. Easy to find, but out of the way.

We've taking the friction out of adding and editing bugs, as well — getting a bug into Fortress takes just a couple of clicks from any bug list. We'll (optionally) use the current query as a template, so a new bug added from the "Milestone 1" list will default to "Milestone 1", tags will be copied, etc.

Updating a bunch of issues at once is easier, too: want to reassign or close some of the items you're looking at? Check them off, and use the quick-edit tools at the end of the list to update them in-page.

We've also eliminated the "printable view" menu item from all pages; bugs, bug lists, etc. will print properly without any extra steps.

Editing a bug's details is easier than ever — when you're viewing a bug, clicking on any of its fields lets you edit the field in place.

The Source Control web interface has been revamped as well; the new repository tree is much faster, cleaner and easier to navigate.

There's a lot more to the beta, from Shelve improvements to the new full-fledged VSS Handoff feature. I'll post again later when it's out; give it a shot, and please let us know what you think in the Beta Support Forum.

You may have seen, or read reports of, Microsoft Security Advisory 971492 (Vulnerability in Internet Information Services Could Allow Elevation of Privilege), which details a potential security hole in IIS's WebDAV service. And you may be aware that Vault 5 and Fortress 2 (both in beta now) offer WebDAV access to version control repositories.

You needn't be concerned for your code's security — even when running under IIS 6 (the version affected by this issue), Vault and Fortress do not use Microsoft's WebDAV services. The code is completely separate, specific to Vault and Fortress, and doesn't access the file system in the way that's causing trouble for Microsoft.

So feel free to keep testing Beta 1 while we work on Beta 2, and keep the feedback coming in the Support Forums.

Vault 5 beta 1 and Fortress 2 beta 1 are now available. We're dogfooding these at the moment, and they're definitely ready for you bleeding-edge types to test out.

Any and all feedback — bugs, installation issues, documentation gaps, etc. — is read, logged and appreciated.

What's in there?

Shelve is in there.

WebDAV is in there.

Crazy-fast VSS Import is in there.

Fluid, streamlined Work Item pages are in there.

We're still polishing of course, and with your input, Beta 2 should be awesome. Thanks in advance...

Something I should not probably not admit publicly (both from a best-practices standpoint, and given that we are a vendor of version control tools):

Until recently, our website was not version-controlled.

There, I've said it.

sourcegear.com is largely maintained by myself and John Woolley, our Director of Graphic Awesomeness.* John's is a Mac-centric universe, and I'm running Windows. For web-maintenance purposes, we both use Dreamweaver.

As you may know, Fortress and Vault both offer Dreamweaver integration; but there are a couple of issues:

1. With each new version of Dreamweaver, the location and requirements for our integration code seems to change. This is not much fun from a support and maintenance point of view.
2. This integration method is Windows-only — which, as you can imagine, makes it less than useful for John.

So John was out in the cold. He's not alone in wanting Dreamweaver/Mac support — it's been a long-time feature request from a number of our customers. But as always, the development team needs to work on the features most requested by the most customers. What we needed was someone with some time on his hands, who really wanted this particular itch scratched...

So last Thanksgiving, unable to move after dinner, I started playing around with a hobby project.*

Dreamweaver, out of the box, supports checkin/checkout/locking via WebDAV. If we had a WebDAV layer over Vault/Fortress, Dreamweaver could use it without any special code installed. Other tools could use it to, and we wouldn't have to worry about specific Dreamweaver versions, operating systems, etc.

So, with excellent test clients and validation tools in hand, off I went.

Within a day or so, this was happening:

Allowing this:

And, with no extra effort, this:

Open standards kinda rock, if you needed any more evidence.

It's been in use every day since.

Starting as soon as next week, you can try out the WebDAV interface yourself, in Vault 5 Beta 1. Watch the Development Blog for details. We'd love to hear feedback and suggestions from the brave, the few, daring enough to use The Code that the Marketing Guy Wrote.*

1. John always tells me to use "whatever title [I] want" when referring to him. He should know better by now.
2. If your hobby project is useful to more people than yourself, think twice before mentioning it to the development lead.
3. Don't worry, the code has long since been vetted, reviewed and revised by the actual development team.

I've been talking to some Vault users who felt that Vault was letting them down — specifically, that the client wasn't helping them spot newly-added files, and make sure they were checked in. Orphaned files lead to broken builds, gnashing of teeth ensues.

It's easy to forget this when (as most of us here at SourceGear do) you spend much of your life using and thinking about IDEs. Using Vault and Fortress in Visual Studio or Eclipse, it takes an effort to keep your project's new files out of version control.

I'll state up front that we don't solve this problem as well as we should at the moment, and we're going to address that. In the meantime, a quick primer on how we do solve the problem — and actually, we do a better job than might be immediately apparent.

There are two ways in which we'll find new files for you.

Ghosts

The first is via the "Show non-version-controlled files ghosted in the file list" and "Show non-version-controlled folders in the folder tree" options. With these enabled, viewing a directory in Vault will show grayed-out, "ghosted" entries for files (or folders) in the working directory, but not in Vault, like so:

The problem is, especially for new files, this is a folder-at-a-time feature. There's no at-a-glance way to see all new files in all subfolders.

Detect New Files to Add

This is better handled by the Detect New Files to Add feature. What's not immediately obvious is how that feature does allow recursive searching of a folder. An example may help.

Here's a simple folder structure — one subfolder, a few files.

Some of these files are checked in to Fortress, some are not:

We fire up Detect New Files to Add

And initially, we see the new file in the root folder (the one folder we're currently viewing).

We check the box next to "dwtest", and Fortress searches this folder and all of its known subfolders, to find non-version-controlled files. Note that the .dll file we saw earlier is ignored — there's a predefined list of file types to exclude from searches like this (which can, of course, be modified on the fly or via the Admin tools).

But what if we don't want to add all of those files? No problem. Select any files you want to kick off the list, then click Remove.

Add a comment, or not, then click OK to add everything still on the list.

What's missing?

The most glaring omission here is that we detect new files only. If you've added a new folder, Detect New… won't spot it. Luckily, this is a much-less-common occurrence, and less likely to go unnoticed. But still. Needs to be better. And it will be.

Speak up

(Hopefully) needless to say, while I'm always happy to hear praise for our products, I'm just as eager to hear what's not working for you. Have a Vault or Fortress pet peeve? A most-missed nonexistent feature? Don't hesitate to let me know.

When we’re not busy putting together real guitars, or playing plastic ones, we’re hard at work on upcoming Vault and Fortress releases.

We’ve got some major new capabilities in various stages of design and development… and Jeremy would like to offer you a peek at what we’re doing in the way of shelving.

One of my recent pet projects is to add a number of videos to the Fortress section of sourcegear.com. Currently, “a number” translates to “three”.

Basically, we’d noticed that while Version Control concepts and features can often be nicely explained in screenshots and text, it’s harder to do on the bug tracking / ALM side of things. Especially when we’re dealing with combined Bug Tracking and Version Control features, and their interaction with IDEs, etc.

But these things are easy, and fun, to show — as we do at trade shows, in person, in our online demos, etc. So the plan is to get as much of that info up on the site as possible.

Why is line history so cool? Let me show you.

How do Fortress “clouds” help you find your way through a forest of Work Items? Let me show you.

And the latest — we’re always encouraging people to take a look at Fortress for themselves. The download’s not huge, the requirements are slight, and installation is quick. But everyone says that, and the installation’s never quick.

So really, how quick? “Minutes”? Really? Take a look.

Thought I'd pass on another PowerShell script I've been playing with. As before, this is bare-bones -- exception handling, usage, help are all missing. But it's doing what I need it to do this morning.

Again, we're using the Fortress Client Integration library, but this time it's a standalone script that you run explcitily. In this case, we're creating simple Fortress Work Items.

The same caveats apply as before -- run vault.exe's REMEMBERLOGIN command at least once before using this script. You'll also need to know the name of the Fortress project you're adding to (the actual name as displayed, no internal ID numbers, etc are neeed).

The script wants the project name, and a description of the bug being added. Quote them if spaces are involved. We'll default the rest of the fields, using values that are present in any new Fortress installation.

Feel free to test this out against fortressbeta.sourcegear.com, by the way. To add to the single project living there, you'd say:

AddFortressItem "Fortress Demo" "Just testing PowerShell, nothing to see here"

Save the following script somewhere in your PoSH path, and name it AddFortressItem.ps1

# AddFortressItem.ps1
# usage: AddFortressItem "Project Name" "Bug summary"

# Paul Roub <paul.roub@sourcegear.com>

param (
        $projectName = $(throw "Please specify the project name"),
        $subject = $(throw "Please specify the bug description")
)

if (! $sgLoggedIn)
{
        if (! $sgLoaded)
        {
                #  at start up -- attempt to load the Vault lib and log in
                #
                #  Vault users -- change "Fortress Client" below to "Vault Client"
                #
                [void] [System.Reflection.Assembly]::LoadFrom(
                        $ENV:ProgramFiles + 
                        '\SourceGear\Fortress Client\VaultClientIntegrationLib.dll')
                $sgLoaded = $true
        }

        #  Log in based on previously-saved (via vault.exe) credentials.  
        #  Will attach to the previously-selected repository
        #
        [VaultClientIntegrationLib.ServerOperations]::Login(
                "Client", $true, $true)
        $sgLoggedIn = $true
}

$newitem = New-Object "VaultClientIntegrationLib.FortressItemExpanded"

#       use the project name and subject from the command line,
#       default the rest
#       
$newitem.ProjectName  = $projectName
$newitem.Description  = $subject
$newitem.Details      = $subject
$newitem.ItemType     = "Bug"
$newitem.Status       = "Open"
$newitem.Platform     = "Unknown"
$newitem.TimeEstimate = "Unknown"
$newitem.Priority     = "Unknown"

#       check the item and get it ready to add
#
$newitem.Validate()

$res = [VaultClientIntegrationLib.ItemTrackingOperations]::ProcessCommandAddFortressItem(
        $newitem)

echo "Added item:" $res.GetMantisItem().ID

We've donated several license bundles as giveaways at the School of Dev event this weekend, in Tulsa, OK.

Up for grabs for attendess: 2 five-user Fortress licenses, 2 five-user Vault licenses.

As always, if you're looking for giveaways, swag, $$$, etc. for your user group or code camp -- drop me a line at paul.roub@sourcegear.com

I've been toying with the idea of integrating Fortress and Vault into Windows PowerShell. PowerShell is, at heart, a scripting wrapper for .NET libraries. Combining that with the Vault Client API (or the equivalent Fortress Client API) seems like a no-brainer.

There are a lot of ways to go here:

• Creating a provider that would enable Vault/Fortress repositories to be browsed as a file system. You could then just copy files to check them in and out, etc.
• Re-writing the Vault/Fortress Command Line Client as a series of PowerShell cmdlets would be a reasonably straightforward task.
• Any number of simple helper functions and convenience commands can be created

For today, not having done and PowerShell scripting before, I'm opting for the last one.

In particular, when I'm in PowerShell, it would be nice to know with Vault/Fortress folder is mapped to my current directory. This is particularly helpful when I have multiple branches of a project in play, and want to see which branch I'm playing with right now.

In action, it looks like this:

At first, we see a typical PowerShell prompt.

In my Documents directory, roughly the same thing.

But Documents\dw-sourcegear maps to the Fortress folder managing sourcegear.com's files. And we see that mapping, grayed, above the prompt.

Moving further into the tree, the Fortress mapping follows along.

The fun part is that this took just a few lines of PowerShell code. The API does all the heavy lifting.

What's the catch? This is not the most-comprehensive approach I could have taken -- it's more a proof of concept. We're piggybacking on the Vault/Fortress Command-Line Client's saved login info, so you must have run vault.exe with the REMEMBERLOGIN option at some point. We're also tied to the previously-selected repository.

Correcting those limitations, or implementing the other possibilities mentioned above, is left as an exercise to the reader (or maybe the writer, given a decent chunk of free time)...

The code itself:

## Display SourceGear Fortress/Vault folder mapped to the current directory
## Paul Roub <paul.roub@sourcegear.com>
##

#  did we successfully log in?
$sgLoggedIn = $false 

#  at start up -- attempt to load the Vault lib and log in
#
#  Vault users -- change "Fortress Client" below to "Vault Client"
#
[void] [System.Reflection.Assembly]::LoadFrom($ENV:ProgramFiles + 
   '\SourceGear\Fortress Client\VaultClientIntegrationLib.dll')
$sgLoaded = $true

#  Log in based on previously-saved (via vault.exe) credentials.  Will attach to 
#  the previously-selected repository
#
[VaultClientIntegrationLib.ServerOperations]::Login("Client", $true, $true)
$sgLoggedIn = $true

#  Replace the default command prompt.  This should be loaded via 
#  your profile.ps1 to work properly.
#
function prompt 
{
   #  set the window title to our current dir
   $host.ui.RawUI.WindowTitle = $(get-location)
   
   #  I like a blank line after the last command.  If you don't, 
   #  comment this out.
   Write-Host ""
   
   #  If we didn't log in, don't bother attempting other Fortress operations
   if ($sgLoggedIn)
   {
      #  If there is no mapped folder here, an exception will be thrown.
      #  Catch it, note the lack of a mapping, and continue.
      trap [Exception] 
      {
         $sgFolder = $false
         continue;
      }
      
      #  Grab the mapped folder as an object
      $sgFolder = 
        [VaultClientIntegrationLib.RepositoryUtil]::FindVaultFolderAtReposOrLocalPath($pwd)
      
      if ($sgFolder)
      {
         #  Get the full repository path, and display it in gray above 
         #  the regular prompt
         $sgPath = $sgFolder.FullPath
         $pval = "(" + $sgPath + ")" 
         Write-Host ($pval) --foregroundcolor Gray
      }
   }
   
   #  Whatever we return will be displayed as the remainder of the prompt
   "PS> "
}

SourceGear Vault 4.1 and Fortress 1.1 were released today. These maintenance releases are both free upgrades for users of Vault 4.0 and Fortress 1.0, respectively. We highly recommend that you upgrade, as these releases contain many performance and stability improvements, plus some very cool new features.

SourceGear would like to thank our user community for all of the testing, suggestions and feedback during our Beta period.

So what's new? Visual Studio 2008 integration, Work Item tracking in the standalone client, more integration, easier image handling, and more.

What's new in Fortress 1.1

(See the release notes for full details)

Tag Clouds

Tag clouds are an exciting new feature in Fortress that allows you to add a few keywords to work items, and then see a graphical depiction of the distribution of those keywords. Similarly, you can view a graphical depiction of the distribution of work items among assignees, milestones, and other work item fields.

New Query Page and support for Saved Queries

The web client has a new Query page and allows you to create, run, edit and delete saved queries.

GUI based work item tracking

The Stand-alone Windows client now has a GUI based bug tracking client.

Easy image attachments

The Windows GUI client, Visual Studio Enhanced Client and the Eclipse client all support pasting image attachments from the clipboard. In addition, a limited image editor is included in order to crop or annotate the image. Also, attachments may be added using drag-and-drop functionality.

What's new in Vault 4.1 (and also in Fortress)

(See the release notes for full details)

Visual Studio 2008 support

This is the first version of Vault that offers integration with Visual Studio 2008.

Legacy IDE options

Users requested a few options available in the Classic Client be implemented in the VS Enhanced Client. The two options that have been implemented are Get Latest when a solution is opened and Check In when a solution is closed.

VS Enhanced Context Menus

The VS Enhanced Client's context menus were rearranged in order to provide easier access to commonly used operations.

Better progress indicators In the VS Enhanced client

The Add Solution and Check In commands now give status as to what is occurring.

Refresh Source Control Status

In the VS Enhanced client, there's a new menu item in the File->Vault submenu to refresh all source control statuses to update file icons in the Solution Explorer.

64 bit support

We've corrected the installer issue that was preventing server installs on a 64 bit OS. IIS will still need to be put into 32 bit mode.

Ant Tasks

Tasks are included for calling Vault source control operations from the Ant build tool.

Java CLC

For users on non-Windows platforms, there is now a Java based command line client.

New Web Diff Page

The Web Diff page has been rewritten to make it more useful for code reviews.

The new betas are out! Fortress 1.1b2 and Vault 4.1b2 dropped today -- see the release notes here, download Fortress 1.1b2, or download Vault 4.1b2.

Vault Changes since Beta 1:

VS.Net Context Menus

The VS.Net Client's context menus were rearranged in order to provide easier access to commonly used operations.

Better progress indicators In the VS.Net client

The Add Solution and Check In commands now give status as to what is occurring.

Refresh Source Control Status

In the VS.Net client, there's a new menu item in the File->Fortress submenu to refresh all source control statuses to update file icons in the Solution Explorer.

New Look

After 5 years with the same icons, Vault now has a new icon set.

64 bit support

We've corrected the installer issue that was preventing server installs on a 64 bit OS. IIS will still need to be put into 32 bit mode.

Project Rename

Projects can now be renamed in the Visual Studio client.

Fix for an unregistered dll

Numerous people upgrading from the 4.0 client to the first 4.1 beta noted exceptions caused by an unregistered dll. This beta should fix those issues.

Fixed Eclipse 3.3 thread access errors

Eclipse 3.3 caused some problems on startup, giving a thread access error.

Other bug fixes

Lots of other minor tweaks and fixes to issues reported in Beta 1.

Fortress Changes since Beta 1:

New GUI based work item tracking window

The new work item tracking window allows you to query, add, edit, and browse work items without leaving the Fortress Client. Also, the new work item tracking window provides all of that capability while browsing for bugs to update with a source control check in.

Image Paste and Edit

The Image paste and edit functionality which was only available in the Eclipse client for the first beta is now available in the Fortress Visual Studio client and the standalone GUI. In addition, work item attachments can be added by dragging files onto the attachment control.

If you're currently using Vault 4.0.x or Fortress 1.0.x, please upgrade to 4.0.6 or 1.0.6. These fix two issues that, though unusual, are no fun whatsoever when they occur.

See the release notes (Vault and Fortress) for more info.

Download Vault here, Fortress here.

It's beta day -- specifically, the Vault 4.1 and Fortress 1.1 betas.

Tag clouds, Visual Studio 2008 support, image paste/edit, Ant tasks, a pure-Java command-line-client, and more. We've set up a beta server for you to play with, and all the bits are available to install and test locally as well.

An interesting detail -- the image paste/edit features are currently only available in Eclipse (they'll be in VS.NET in a later beta). I'm pretty sure this is the first time a new feature has shown up in Eclipse before VS.

See the beta announcement for details.

In talking with SourceGear customers, and with current or recovering SourceSafe users, and -- to be honest -- in my own past history, a painful task occurs all-too-frequently. I'm talking about the manual "push to production" of a particular fix, feature, or set of files for a web site. Just that set of files, no more, no less. And sometimes it's tricky.

We had a customer ask recently how Vault might help them:

1. Find just the files associated with a particular update...
2. Warn if any of the files involved included changes for later, as-yet-unapproved updates...
3. Fail in that case, otherwise...
4. Copy those files to production

or in a more-perfect world,

1. Move the affected files as they existed at the time the fix was checked in
2. Unless later overlapping fixes have been pushed, in which case the latest approved-to-be-pushed version should be used

Having fun yet? They're not.

It's a common setup -- imported as-is from SourceSafe; a single folder hierarchy for development; production is not under version control; and dev is at least several features ahead of production.

While we did discuss means by which they could use Vault's Client API to script this sort of thing, I'd like to demonstrate how they might get off that treadmill, save themselves a ton of manual labor, and bring production under control.

Jeremy has launched the SourceGear Development Blog -- where we'll give you a peek at upcoming features (including some that are still on the drawing board), as well as beta schedules and progress reports.

For now, the focus will be on the Fortress 1.1 / Vault 4.1 development cycle. Stay tuned.