But I haven’t been lying in bed eating deep fried Twinkies all this time.  The next major releases of Vault and Fortress are creeping up, and I’ve been hard at work on them.  I made some major infrastructure improvements to Vault’s merge feature that will pay big dividends in the future.  I also tackled a couple of long-standing feature requests in the Visual Studio integration that were too big for a minor release.  Jeremy’s blog will have the juicy details.

IDE-integrated source control would be so much easier to use if the whole concept of binding just went away. There’s a huge number of complications that arise from binding and varying opinions on how it works, actually and theoretically. Making IDE-integrated Vault work without binding is theoretically possible, but it would require pretty significant fundamental changes to non-IDE-related functionality. I think about it frequently, but it’s difficult to make the case that the benefit would be worth the cost.

It seems to me that with ten fingers, the natural convergence point for the human race should have been a base-11 written numerical system: you should run out of symbolic digits when you run out of physical digits. In base-10, you have to add a new column when you’ve still got one finger left! What a hack! Strangely, a half hour in Google and Wikipedia reveals no evidence of any non-fiction tribe or civilization, ever, that used a base-11 system. This gives me pause: what else do I consider perfectly reasonable and elegant that is demonstrably absurd?

I spent 9 days on Kentucky Lake this summer, sans laptop, and actually got ridiculously tan. Linda in support, (a professional people-person) mocked my bleached white eyebrows when I got back.

I’m reading Michael Lopp’s Managing Humans. I’ve read his blog for years, so in theory I’ve already read most of this, but I still find the book to be excellent. It’s both entertaining and informative. His writing style translates exceptionally well to dead-tree format, in my opinion. Lots of his advice pertains mainly to working in companies much larger than SourceGear, but I’m still enjoying it tremendously.

This seems like as good a place as any to thank the many early adopters who took part in the beta for this release. In no small part due to your help, we made significant improvements in the usability and performance of the Visual Studio Enhanced Client (formerly the Visual Studio 2005 client).

For developers who use IDE integration, particularly those upgrading from a 3.x version, I recommend checking out this FAQ.

All of the graphical clients (Windows, Visual Studio, Eclipse) also got a face lift with this release. The FAQ includes a few screen shots.

Finally, if you’d like to keep abreast of all Vault and Fortress-related releases, there is an RSS feed for our release announcements.
]]> http://ianolsen.com/2008/02/20/vault-41-fortress-11-ships/feed/ 0 ianolsen Vault Fortress http://ianolsen.com/2007/11/27/vault-41fortress-11-beta-1-available/ http://ianolsen.com/2007/11/27/vault-41fortress-11-beta-1-available/#comments Tue, 27 Nov 2007 16:24:39 +0000 Ian Olsen http://ianolsen.wordpress.com/2007/11/27/vault-41fortress-11-beta-1-available/ ]]> Last night we released a beta version of Vault 4.1 and Fortress 1.1. The big changes include:

• Visual Studio 2008 support
• Tags in Fortress

A more exhaustive list of changes is here.

• Adding an existing unbound project to an existing bound solution now works correctly.
• Projects that are pending addition no longer always give a spurious working folder error on startup.
• Added help for the “Add Solution to Vault” and “Change Vault Bindings” dialogs.
• Fixed a bug where the path to web site projects was not always correctly determined in the Change Bindings dialog.
• Changed some text to make it more clear that you’re going offline: login dialog and working folder resolution.
• Adding a new web site project to a bound solution now gives a sane default repository location.
• Solutions and projects are now correctly reloaded when undoing a change from the pending changes window.
• Log out from the repository now happens correctly when closing your solution after it had been automatically reloaded due to a get or revert.
• Get Latest and Checkout commands are now enabled when only a child file (e.g. a designer or code-behind file) is selected.
• Fixed the weird availability of the “Open From Vault” command. It’s now always available when we’re the active source control provider.

These will be in 4.0.5 final, due out Real Soon Now.

Most of the changes in this release are in the Visual Studio integrated client, for which it’s the biggest release since 4.0/1.0. People using that client should definitely check it out.

Noteworthy changes to the Visual Studio client include:

• There is a new binding management dialog that allows people with more sophisticated binding requirements to work effectively. It’s now possible to have an unbound solution and bound projects, for example.
• Get Latest has been significantly improved. Specifically, it’s no longer necessary to perform the command twice when files have been added to a solution or project. You also no longer get annoying “This file has changed, reload?” prompts.
• The bin folder in web site projects is now handled correctly. (Rejoice.)
• Solutions having projects that aren’t beneath them in the file system are handled significantly better.
• Solutions having multiple Business Intelligence projects now work.
• The performance of Add Solution has significantly improved.
• Linked file checkouts are handled better.
• The pending change list better reflects checkout status.
• Session restarts are handled better.

The full release notes are here. If you’re using the new Visual Studio 2005 client, or you’ve had trouble with it in the past, take a look!

Also, if you’re interested in other things happening in Vault/Fortress development, check out the SourceGear Development Blog.

We don’t have to deal with dependencies for our builds at SourceGear, but we did have to resolve some serialization issues when we first set it up.

We have five projects currently built by CruiseControl.NET:

• Dragnet 1.0.x
• Dragnet Trunk
• Vault 3.1.x
• Vault 3.5.x
• Vault Trunk

For people whose build times run into hours, it’s important to build as little as possible to fully reap the rewards of Continuous Integration. Including all unit tests, Vault builds in about 45 minutes, and Dragnet less than that. We have a smaller set of tests that runs on every checkin to get Vault’s time down around 20 minutes. We essentially build all the code for every build on each of these projects, sparing us the dependency issues. Still, there are a couple of reasons we couldn’t just allow anything to build at any time:

1. The unit tests require that the Vault server be installed and you can only have one instance of a Vault server installed on a machine. We can’t have multiple Vault builds trying to install the server willy-nilly.
2. We use Wise for our installers, and strange things happen when multiple instances of it are running.

Initially, I cobbled up some modifications to CCNet to only allow one build at a time. This worked, but it sometimes made the wait for a build much longer than it had to be. In our configuration, when CCNet does a build it’s actually doing all these things:

1. Clean out the source directory
2. Get the latest source
3. Build
4. Create installers
5. Install server
6. Unit tests
7. Uninstall server
8. Label source

My modified version of CCNet essentially made the entire process one big critical section. It was effective, but far from optimal. At one point last fall someone on the mailing list mentioned that they had created a mutex script in NAnt that gave them finer-grained locking. John Hardin at CRS Retail Systems was kind enough to save me the effort of rolling my own and provided his script.

Adding this block to your NAnt script gives you the ability to add named mutexes as NAnt tasks. In our configuration, steps 3 through 7 are all performed within a NAnt script that CCNet kicks off. For the Vault builds, steps 5 through 7 are encapsulated by a mutex. Each build waits for it’s turn to install and test a server:

<mutex mutexName="VAULT_SERVER_MUTEX" />

<!--
Install Server...
Do Unit Tests...
Uninstall Server...
-->

<mutex mutexName="VAULT_SERVER_MUTEX" />

We did the same thing with a “Wise” mutex for the parts of the script that create the Wise installer.

The NAnt mutex method is just as effective as one huge lock from CCNet, but because we’re locking only when necessary, builds spend a lot less time waiting for others to finish. And we no longer need to run a customized version of CCNet.

Even if CCNet includes serialization features some day, I can’t imagine that this level of locking would be possible. Once you’re running NAnt (or MSBuild, or whatever) you’re outside CCNet’s control: locking within NAnt itself ought to be a useful trick for some time.

As a quick reminder, to take advantage of the fixes in CCNet you also need Vault 3.1.8 or better, both client and server.

If you’re upgrading from 1.0, make sure to take a look at the Vault Source Control Block documentation, as a number of things have changed. In particular, you may need to change your useWorkingDirectory and workingDirectory settings to get the same behavior you had under CCNet 1.0.