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

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.

FYI, we’re sponsoring the Western New York .NET User Group’s June 18th meeting.  So expect some comics, T-shirts, and a Fortress license giveaway.

And don’t forget, if you’d like for SourceGear to sponsor your User Group or Code Camp, drop me a  line at paul.roub@sourcegear.com

TechEd/developers 2008 was a lot of fun, and extremely tiring.  The combination of plans gone astray, unplanned events, and things which couldn’t be planned for kept life interesting.

Plans Gone Astray

As at SD West, we had announced that we’d be giving away Fortress licenses to those who could beat Jeremy at Guitar Hero.  Gauntlets were thrown. Smack was talked.

And then Jeremy had to fly back home, unexpectedly, before the show started.  Our Artistic Director, John Woolley (the man behind the Evil Mastermind) bravely stepped into the breach and took on all comers.

John’s good, but by his own admission not freakishly good like Jeremy.  He still turned in a near 50/50 win/loss ratio.  It probably would have been higher if I hadn’t stepped in for a few rounds.

The gallery of winners can be seen at flickr

Also, it certainly seemed like 900 shirts would last at least a few days.  As opposed to barely squeaking through the first day.

Unplanned Events

Things I learned while setting up for the show.  Or, things which should have been completely obvious beforehand:

1. Show setup day, on site, is not the time and place to install OS updates.
2. Especially Windows Service Packs.
3. Always check that you have the very latest drivers for your video card, before replacing it when it stops speaking to a Cinema display.
4. Especially following a Service Pack update.

Fun times.  All worked out eventually. 

How Do You Plan For…

The TechEd Jam Sessions?

We did slightly, of course.  But Jeremy was our bass player, so some additional uncertainty was thrown in.  An Expo day pass for my brother gave us a ringer on drums, at least :-)

So up we go, Eric on acoustic guitar, me on the Evil Mastermind Schecter, Brad on drums, and a cast of several on guitars, keys, bass, percussion.  All watching and listening as we shouted or showed chord changes.  And it went pretty well just the same.

Sadly, the battery died in the camcorder a minute and a half in.  Also not according to plan.  But here’s what we do have:

Next up…

PDC and DevConnections in the fall.  Plenty of time to plan.