Our entire dev team is soon to embark on a project that will become pretty much all-consuming for the next several months, and we’ve been talking about source control. We’ve been using VSS for a long time, mainly because we already have it. But when you lose an entire day of productivity across the entire dev team, because VSS can’t do the branch on account of a corrupted data store that takes more than eight hours to repair, it’s time to look around.
We’re pretty much in agreement about the qualifications of our dream source-control system. The #1 feature we want is the ability to check something in, but not have that change hit the official build until it’s been code reviewed and system tested.
Borland StarTeam has that capability (though it remains to be seen just how much we have to pay to get that feature). It’s got a built-in bug database, too, and it should be able to automatically tie individual check-ins to individual bugs/enhancements (which is a dream feature of mine). We’re investigating a couple of other high-end source-control systems as well, but I’ll have a good chance to get up close and personal with them at BorCon — I’m taking a preconference tutorial on how to write tools that integrate with StarTeam (#2010, Sunday afternoon).
Microsoft’s Team System might hold some promise, if they’d just get off their asses and start talking about pricing. They refuse to even hint at what the bundling and pricing are going to be. It could be $50 a developer, it could be $50,000, it could be free. And, of course, it won’t be released until sometime (probable translation: December) next year.
Also on our radar is SourceGear Vault, which is much more reasonably priced (around $200 per developer, instead of “it’s too expensive for us to print the price on our Web site” for the top-end version of StarTeam). Vault has some of our “nice to have” features, like atomic check-in. It doesn’t have the “must be code reviewed before it can be part of the build” dream feature (not surprising given its price range). But one thing it does have is a positively dreamy diff tool. Here are a couple of screenshots:
It can do diffs within a line. This is a feature I’ve wished for in VSS for I don’t know how long. (Let’s see, how long have I been using VSS…?) Any time I rename a variable, all VSS cares to tell me is that more than half the lines in my method have changed. Vault’s diff will actually tell me that it’s just the variable name that’s changed. Sweet!
This one really got me. Vault can diff across line breaks. Is that cool, or what? (This is especially nice since we changed our coding standards, oh, about three years ago, to say that the “begin” of a Delphi begin..end block should now be on its own line, not the end of the line with the ‘for’ or ‘if’ or ‘while’. And of course, not all of the code has been brought up to standard yet. VSS would just show us gray lines whenever we fixed one of these, and if the condition changed too, we might miss it. Vault can show us that the only thing that changed was a line break.)
Vault is meant to be a drop-in replacement for VSS, which means it’s got VSS’s design limitations — for example, if you’re going to branch off the release version, you have to create a new folder for it (my understanding is that StarTeam, and some others, let you maintain multiple branches within the same folder tree). However, this closeness of design does mean that, if we’re going to change source-control systems before our Big Project, Vault is really the only contender; we don’t have time right now for the steeper learning curve for something like StarTeam. But after the Big Project, we may be ready to switch to something high-end (budget permitting), so it wasn’t clear whether it’s worth it to shell out money for Vault now, only to possibly spend more later.
But I think Vault’s diff makes that decision a lot easier…
(A warning, though: Don’t do a diff on two multi-megabyte PDF files. It’s not so good at noticing that these are binary files. It works, more or less, but it takes a while.)