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.

Remember that SourceOffSite CTP release I mentioned? It’s here. Jeff has the details if you’d like to try it out.

Why are we doing another update of SoS? Shouldn’t everybody just get away from SourceSafe and into Vault or Fortress? In a perfect world, sure.

But we know a lot of you are still living with SourceSafe, now and in the forseeable future, for all the usual reasons — time, budget, inertia, IT priorities that outrank your SCC provider. And we feel for you, and want to continue helping via SoS.

And now, we can help even more.

A folder-spanning “pending changes” window, so you don’t forget to check in one of the 50 file in your latest web update? Got that.

Multiple tabs, allowing you to keep tabs on your searches, your history, and everything else in your multitasking day? That too.

Performance? Yep. Stability? Sure. Modern UI? Gotcha.

Give it a shot (Windows only right now, BTW) and let us know what you think.

As Jeff notes at the SourceGear Development Blog, a preview release of SOS 5 is coming your way very soon.

Watch the Development Blog for details. Jeff and the team are justifiably proud of this release.

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.

Often, and ideally, version control, bug tracking and other dev tools are chosen in a grassroots manner. Programmers find the tools they want / need / like, and become unpaid evangelists, or vigilante marketers, or whatever phrasing would read best on a T-shirt. I was always one of those guys, going back to promoting RCS as the go-to tool for the Xenix environment at my first summer internship.

Now I’m paid to help those people — if I’m doing my job, they’re the target audience for most anything I do. Sometimes, that’s lobbying to push the features they want higher on the priority list (often because I want them, too). And sometimes, it’s being asked for “a little ammo” by someone who wants his team to move to Vault. But his manager knows Subversion is free, and doesn’t see why Vault would be such a better fit for their team that they’d spend money on it.

So for that guy, and the other guy asking for the same thing a day or two later, we’ve posted a “Vault vs Subversion” white paper. It’s short (so your manager will be willing to read it), mostly non-technical (ditto), and focuses on the reasons a Windows-based shop will often find Vault an easier, better, cheaper-in-the-long-run fit. It might also convince a fully-Linux-based shop, using an IDE we don’t support, standardized on MySQL as the sole database platform, that Vault is not the best fit for them. Either way, time saved, questions cleared.

Expect “Vault vs VSS” and “Vault vs CVS” papers in the future, when I can figure out how to expand them beyond “well, duh”.

Or so it would appear.

We’re co-sponsoring 4 upcoming code camps at the moment - contributing money, swag, and Fortress giveaways. And we’d be happy to help out with yours (or your user group meeting) as well — just let me know

Here’s the list as it stands at the moment:

Southwest Florida Code Camp: Saturday, September 13, Estero, FL

Central Coast Code Camp: Saturday and Sunday, September 27th and 28th, San Luis Obispo, CA

Argentina Code Camp: Saturday, October 4, Universidad Abierta Interamericana

Jacksonville Code Camp: Saturday, October 23, Jacksonville, FL