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:
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:
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.
(See the release notes for full details)
(See the release notes for full details)
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.
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:
or in a more-perfect world,
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.
This page contains an archive of all entries posted to Paul Roub in the Fortress category. They are listed from oldest to newest.
Evil Mastermind is the previous category.
release is the next category.
Many more can be found on the main index page or by looking through the archives.
