Vault roadmap; future release plans

[dwenzel]

I was just wondering if sourcegear has published a roadmap for the Vault product.

[ericsink]

I was just wondering if sourcegear has published a roadmap for the Vault product.

Sorry, no. We currently are dropping a few hints about our next release, and saying nothing about the release after that.

Those hints about the next release are repeated below:

Off the top of my head, here is a list:

Several improvements to performance, especially for larger teams

Bug-tracking

Some improvements to merge branches

Email notifications

Bunches-o-bug-fixes

New dialog for adding files, much easier

New dialog for setting working folders

Much improved handling of files in status "unknown"

Greatly simplified license tracking

[bushidocoder]

Is Windows Authentication / Active Directory support for users in the 2.1 roadmap?

[dwenzel]

Thanks. Any future plans on making the diff tool so that you can add/delete/checkin/checkout like you can in VSS? I understand the diff/merge tool is separate from the Vault client and would require some type of interprocess communication. I have to say that was a *very* useful feature in VSS, and I have not figured out a convenient way to "reconcile" project differences using Vault.

[jeremy_sg]

Is Windows Authentication / Active Directory support for users in the 2.1 roadmap?

Yes, Active Directory will be supported in 2.1.
See this thread: http://support.sourcegear.com/viewtopic ... +directory

Vault 2.1 will allow users to use their domain password to authenticate with Vault. There are some things to note:

* The Vault admin will still need to manually create each user account. The Vault username must match the Active Directory username.
* Vault only asks Active Directory to authenticate the user. Vault doesn't check any properties of the user's AD object.
* The Vault admin can specify which users authenticate against AD and which ones do not.
* All users must authenticate against the same domain. The domain to authenticate against is configured in the Vault Admin tool.
* There will be no special handling on the client side to automatically log the user in if they're already authenticated against the domain. The user will still have to type in his password or use a login profile.
* Groups are still configured only by the Vault admin tool and are not checked against AD.
* Security rights are still configured only by the Vault admin tool and are not checked against AD.

[dan]

Thanks. Any future plans on making the diff tool so that you can add/delete/checkin/checkout like you can in VSS? I understand the diff/merge tool is separate from the Vault client and would require some type of interprocess communication. I have to say that was a *very* useful feature in VSS, and I have not figured out a convenient way to "reconcile" project differences using Vault.

Vault tries to accomplish the same thing via the "Status Search" pane, which will just be called "Search" in 2.1 From there, you can search for any files that are different from ones in Vault.

In a future release, we plan to add more functionality to that pane, so that you can check out files or apply other operations directly from that pane.

[bushidocoder]

I'm not sure Windows Authentication in that form has any benefit over the authentication you have in Vault now.

In fact, since we're a defense contractor and given that we pass you our domain credentials, you remit them to the server and handle the authentication against AD internally, I can see us not using it unless you've had your authentication code auditted as that's a possible entry point into our system - That username/password combo enables access to so many other resources. Part of the idea of Windows Authentication is that no application outside the digitally signed Microsoft components has access to the user's credentials - only the authentication token.

[jeremy_sg]

As I said in the other thread, the goal was to allow admins to use AD to enforce the strength of the passwords set by their users. Because Vault must work seamlessly over the internet, passing windows authentication tokens isn't an option. Perhaps Passport would be the appropriate solution.

I'd never heard that argument for tightening AD integration before, and it makes a lot of sense. When we revisit security next, I'll bring that up.

[Tim]

Any chance of IDEA IntelliJ integration being somewhere on that roadmap? There is definite intrest.

Some of the smaller features hinted will definately improve the product (great as it is - I never problems).

IDEA integration would definately be one of the larger features (got to implement a couple of well defined interfaces), it would not improve product quality but definately increase the potential customer base, but also workload. Compared to other IDEA source control products that have IDEA integrations, Source Vault is a bargain. Possibly a later product release?

-Tim

[ericsink]

Any chance of IDEA IntelliJ integration being somewhere on that roadmap? There is definite intrest.

Some of the smaller features hinted will definately improve the product (great as it is - I never problems).

IDEA integration would definately be one of the larger features (got to implement a couple of well defined interfaces), it would not improve product quality but definately increase the potential customer base, but also workload. Compared to other IDEA source control products that have IDEA integrations, Source Vault is a bargain. Possibly a later product release?

-Tim

I can confirm that IDEA integration will not appear in out next release (now called Vault 3.0). However, we're getting a lot of requests for this, so its priority is going up. Thanks!