Next Version of Vault

[andrew00]

What's in store for the next major version of Vault? I promise not to hold you to anything you say...

[ericsink]

I promise not to hold you to anything you say...

Really? In that case, our current plan for the next version of Vault is to rewrite the entire product in Forth using a curses-based UI.

[ericsink]

What's in store for the next major version of Vault? I promise not to hold you to anything you say...

OK, let's see if I can offer a more constructive response.

We haven't announced anything, nothing here is official. We're mostly still drowning in tech support from the deluge of people interested in 2.0. Etc etc etc.

The next release will likely be called version 2.1. It will be a minor feature release.

Bug tracking is one of our next priorities. We'll be offering a top-notch bug tracking tool which is well integrated with Vault.

We want to give a lot of focus to "annoyances" reported by our customers. For example, it's time to finally fix the Add Files dialog by giving it a filter.

We've talked a lot about email notifications.

Hmmm. I guess that's about all I can say for now. We're starting to firm up a 2.1 feature list, but it's still jello.

[gmagana]

Hmmmmm.... I'm salivating already!

[Guest]

What's in store for the next major version of Vault? I promise not to hold you to anything you say...

OK, let's see if I can offer a more constructive response.

We haven't announced anything, nothing here is official. We're mostly still drowning in tech support from the deluge of people interested in 2.0. Etc etc etc.

The next release will likely be called version 2.1. It will be a minor feature release.

Bug tracking is one of our next priorities. We'll be offering a top-notch bug tracking tool which is well integrated with Vault.

We want to give a lot of focus to "annoyances" reported by our customers. For example, it's time to finally fix the Add Files dialog by giving it a filter.

We've talked a lot about email notifications.

Hmmm. I guess that's about all I can say for now. We're starting to firm up a 2.1 feature list, but it's still jello.

Just my opinion but bug tracking tools are a dime a dozen (there are lots of open source free ones). Vault still looks a bit feature poor in the core SCM when compared to say Perforce.

[montek]

Just my opinion but bug tracking tools are a dime a dozen (there are lots of open source free ones). Vault still looks a bit feature poor in the core SCM when compared to say Perforce.

I agree 100% on this. I don't need a bug tracking tool or integration with Vault. What I *need* is (a) diff/comparing local and network files to what's in the Vault, (b) to have the Vault client be able to actually READ the files on the disk and synchronize, instead of just saying UNKNOWN; this is especially important because if you extract stuff out of the command-line tool, the darn client doesn't have the slightest idea what you've done, and (c) ways to get files to places *OTHER* than the working folder, including the local disk, network locations, and multiple locations.

We have not yet upgraded to Vault 2.0 and I'm tying to find a feature list, but from the looks of things some of the long-awated features I was hoping for didn't make the cut. I don't need bug tracking issues; I need some additional features in the fantastic source-control product we have.

[lbauer]

Vault 2.0 features are listed here:

http://support.sourcegear.com/viewtopic.php?t=163

[dan]

(a) diff/comparing local and network files to what's in the Vault

In 2.0, you can diff repository or working folders/files against any local folder/file. It is not part of the Add operation, which many have requested, but the diff itself can be done from Vault.

(b) to have the Vault client be able to actually READ the files on the disk and synchronize, instead of just saying UNKNOWN; this is especially important because if you extract stuff out of the command-line tool, the darn client doesn't have the slightest idea what you've done

This still exists (handling Unknown files badly), BUT, it shouldn't be the case that doing a Get from the command line would make the files Unknown in the GUI client, UNLESS, the files were retrieved to a non-working folder. By definition, a non-working folder doesn't have Vault state associated with it, which makes the files unknown to Vault later.

(c) ways to get files to places *OTHER* than the working folder, including the local disk, network locations, and multiple locations.

Unless I am misunderstanding, this is already possible in Vault. Just use the -destpath parameter in the CLC, or change the "To:" field in the Get dialog, and Vault will put the files in any folder you specify. They will be Unknown later (if you try to set your working folder there), but they will be retrieved elsewhere.

As for bug tracking - yes, this will not be important to a number of folks, but we've had enough consistent requests from enough customers that we are committed to doing it.

Thanks for the feedback though - we do prioritize Vault features based on what we hear from actual customers.

[24Seven]

Right now, IMO, Vault's (and SourceSafe's) biggest weakness is its integration with SQL Server development. I would like to see features that allow me to check in/out table structures as well as stored procedures AND sync the data in the database with my local development system. It is this last point where most SCM programs fail. Visual Studio's SC in this area frankly blows AND it doesn't simply handle the data.

My developers need to have lookup lists, static data values settings as well as test data. Right now, the most effective and simpliest method is to check in a full backup and have the developers restore from that backup. That's a pain.

[dan]

This is oft-requested functionality, but it is really beyond our control. We provide SCC services to the IDEs - it is up to the IDEs to support better (or any) integration for developing SQL apps. Since Vault was built on SQL, believe me, we feel your pain.

But, we don't really want to be an IDE provider. We like concentrating on SCC