Fortress and Cruisecontrol

[Zarty]

Sorry, this is pre-sales support...

1. I can see that Fortress has some extra functionality for bug tracking and a few other things compared to Vault but, in practice, what are the main reasons for buying Fortress as opposed to Vault?

2. Has anyone out there experience with recent versions of MS TFS and how does it currently compare as a product with Vault/Fortress? I read somewhere that TFS doesn't support shared folders/projects... This was a useful Vault feature that we took advantage of in the past.

Clive

[Beth]

1) Fortress is for those looking for another layer to managing their code and their team. Here we use it for our meetings, our planning, bug reporting, and moving tasks along through our application life cycle. Some other users may use it strictly for bugs, or for receiving bug reports or requests from customers, or for just planning tasks for their team. Then the code one checks in has a tie to the items that it deals with so there is an extra layer of documentation as well.

2) Here is some of the feedback we receive from our customers on why they’ve chosen us over TFS:

• - Easy Install: SourceGear Vault and Fortress install in under 5 minutes, and run with virtually no maintenance [see our install video for proof: http://sourcegear.com/fortress/video/in ... html#media]. Compare this with TFS, which can require days to install and configure, and frequently requires professional consultants.
  
  - Maintenance: Most TFS users report that it requires 1.5 - 2 full-time IT professionals per server to administer TFS. Vault has virtually no admin costs.
  
  - Cost. Vault is $249/user, one-time-fee. That’s less than the cost of just the Client Access License (CAL) for TFS. Additionally, the Vault server is free; with TFS the server is $2,500 per instance.
  
  - Real-Time Support: When you call or e-mail us with a question, you’ll speak with professional technical support and engineers who helped design Vault, not an overseas call center.
  
  - Complexity: Unlike TFS, Vault was designed with small-to-mid-size teams in mind. It’s easy to understand, has a familiar User Interface, and there’s virtually no learning curve for VSS users, and requires little to no training.

[AjarnMark]

Zarty, I want to jump in here and add some emphasis to one of the points that Beth made. She mentioned that in Fortress you can tie your check-in changesets to one or more items in the issue tracking portion of the system. As the manager of a team of a half-dozen developers, some senior, some junior; sometimes working all on the same system, sometimes working on disparate systems; that feature has proven extremely valuable to me. The information it provides can be referenced from two directions, and I have used them both.

The first direction is to answer the question, "Why was this piece of source code changed?". Whether it is triggered off of our list of files changed since the last release (Vault's Show History, On or After Label...) or while debugging an item and wondering why the previous change, which may have introduced your current bug, was done so you don't accidentally undo the previous intent, this has come up several times. To answer this question, I can just go to the Show History of the particular source file and in the comments it has "Item:XXX ...." which is the Issue tracking item number that it was tied to at check-in. Then I can go look up that item and I have a much better handle on what was being attempted. This is far more reliable than going back to the developer and asking them why they made a certain change, especially when that change was just a small part of a larger changeset. Oftentimes the developer has long-since moved on to many other items, and without knowing which bug triggered the event, it is often hopeless.

The other direction where the information is valuable is when you want to know "What all had to change to fix this bug or make this enhancement?" Whether you are using it to justify why Developer A spent a whole week on "one little item" or, more drastically, for some reason that item is being canceled, pulled out of the version, or otherwise you need to know exactly what changes were made, when you look at the item in the Issue Tracking section of Fortress, you have links to not just which files were changed, but which version of the history the change represents. You can then click right on the version number in the web page, or go to the full client GUI and run DIFFs if necessary.

Obviously, I'm a big fan of the product, and you can read my ful testimony here: http://support.sourcegear.com/viewtopic ... 988#p48564 if you want to know more.

[Zarty]

Thank you Beth and Ajarn,

I have a much clearer view of why Fortress might be be used now. As for TFS, the comments made by beth ring true. I get a sinking feeling in my stomach when I try to gather information about TFS Source Control whereas Vault/Fortress is relatively simple and easy to maintain... I was responsible for replacing VSS with Vault with a previous employ and used Vault as part of a database build process that I developed. The senior developer I worked with on that project loved Vault and, as a DBA, it was great too because the SQL database slotted right into existing db backup and maintenance procedures with very little effort. We're about to kick off a project to select a new Source Control tool and some members of the team would prefer TFS hooked into SharePoint. I would like to stack up a case for Vault/Fortress. One extra TFS issues I found out about the other day is that TFS does not provide Folder/Project sharing, which we used extensively in Vault. Maybe I can make a good case of adopting Vault/Fortress. I sincerely hope so.

Clive

[lbauer]

If you want to learn more about Fortress, we have free weekly online demos where you can see Fortress in action and ask questions. Sign up here:

http://www.sourcegear.com/fortress/demo.html