Source Control: Anything But SourceSafe

blog
1

Everyone agrees that source control is fundamental to the practice of modern software development. However, there are dozens of source control options to choose from. VSoft, the makers of FinalBuilder, just published the results of their annual customer survey. One of the questions it asked was which version control systems do you currently use, or plan to use, in the next 12 months?

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/08/source-control-anything-but-sourcesafe.html
2

My post re Subversion wasn’t in reply to Brieuc’s post, though it might look like it, as it appears right after that post and just happens to be phrased as if it might be a reply! I was already typing it before Brieuc’s appeared.

I think Brieuc is right that you shouldn’t be relying on the computer to do an automatic merge for you. But that doesn’t mean that an automatic merge is the wrong thing to do.

It depends on where the human input comes in. If you have good management which distributes relatively orthogonal packages of work to different developers, then each of them can work away on their own branch, and the merge process should be (hopefully) painless, or at least easily resolvable where conflicts emerge.

If you don’t manage the process ahead of time, then merging can be a nightmare. Everyone’s branches are stepping on top of everyone else’s, and you can end up with merges that look like they’ve succeeded, but are actually semantic nonsense.

I think it’s Steve Berzcuk who says that SCM is no substitute for management.

3

[branching and merging] is even dangerous in my opinion

Well, so is working with other developers. Don’t confuse the tool with the problem…

My point is not branching and merging is dangerous. It is necessary in most real life software development projects. That being sayed, I strongly advocate manual merging after a long trip outside of the main branch.

As you point out, working with other developers is a complicated task, and in my opinion, it requires sometimes a bit of explicit synchronization and communication.

I feel like relying on a tool for this task even humans have a hard time to get done properly is simply an easy solution that enables us not to have to discuss with the busy guy at the other side of the room (or world) who is working on a different part.

4

I’ve used Perforce for several years and couldn’t be happier. They support all the main platforms and even some obscure ones.

I switched from SourceSafe years ago after getting sick of constant database corruption and slow performance. Ten years later, it looks like VSS still has the same issues. How sad that Microsoft won’t fix or kill this broken product!

5

Oh, how I wish I could use VSS. We used to use it where I work and it was GRRRREAT!!!.. compared to what we use now: ClearCase.

ClearCase : Source Control :: A barrel of rabid zombie vampire monkeys :: ANYTHING

6

We were using CVS but changed to Rational Clearcase about a year ago.

We’ve had nothing but pain since. It’s slow, it’s expensive, it has no decent reporting, it’s user unfriendly, and it randomly spits up errors take take days of tech support to resolve.

7

I haven’t had yet the pleasure of experiencing VSS, but I think it would be good to follow the advice of some pragmatic programmers ( http://www.pragmaticprogrammer.com/ppbook/index.shtml )* and use a good source control system for your own work in parallel with VSS if you’re forced to use it. It would certainly put your mind at ease, and if the dreaded moment should arrive you can at least be the clever one in the corner with the ‘I told you so’ smirk on your face (pleasant work environment be damned).

  • they suggest doing this when your team doesn’t use source control at all… but it definitely still applies :wink:
8

SourceSafe teaches developers bad habits: avoid branching, exclusive locks, easy permanent deletions.

On the exclusive locks point – what process/tool are people using for group development of multimedia files? I coordinate a lot of non-technical people who produce multimedia software tutorials that don’t fit the ‘merge’ metaphor.

Them not being able to exclusively lock binary files like these seems like a disaster waiting to happen.

I’m in a current search for a better solution than sourcesafe and would be interested in the input.

9

Brieuc, you start with the claim “I don’t agree source control is fundamental to the practice of modern software development.”, but then you point out potential problems with “automated merging”, not “source control” in general.

Source control is more than just merging and branching. It’s a centralized repository of all changes and states of the project since it was put into source control. It allows you to roll the project back to the exact state it had when you rolled it out to a certain customer. It tracks who made what changes, when. (Granted, this information can be misused, but it can also be important.) It provides an easy and supported way for multiple developers to easily work together, even on the same files at the same time, and defined mechanisms for resolving the conflicts.

And perhaps mo$t importantly of all, “the source code itself is checked out on every programmer’s hard drive – I’ve never heard of a project using source control that lost a lot of code.” - http://www.joelonsoftware.com/articles/fog0000000043.html

This isn’t even a complete list of benefits, which would really be a waste of time to type into a comment box.

I tend to agree with you about not doing long term merges automatically (mitigated by the fact that if both trees did good unit testing and the post-merge product runs all the unit tests, it’s a pretty good sign, but it’s a good bet if you’re not even using source control you’re not using any automated testing either… yeah, technically unrelated but I’ll take that bet), but you’re chucking an awful lot of great stuff out just so you… errr… won’t have a maverick developer do an automated merge against your will? Seems like there’s better ways to enforce that than to not use a vital tool.

10

Them not being able to exclusively lock binary files like these seems like a disaster waiting to happen.

Right. Share-Modify-Merge only makes sense if the file types you’re editing aree fundamentally mergeable. Text files are mergeable; MP3 files, not so much.

A modern source control system defaults to shared checkouts, but it also gives you choices for these unmergeable file types:

  • shared checkout (share-modify-merge)
  • write lock (guaranteed first check in)
  • read lock (exclusive lock)

In your case, the designers would place write or read locks on the binary files they’re checking out.

11

Yes Jeremy, I 100% agree with you on the central repository part. But this is old stuff, it doesn’t require the latest source coutrol system with a bunch of nifty features. Any source control system has this very basic functionality.

And any source control system is sufficient for automated builds and unit tests. No need for the last hype system.

My question is only about the benefits of new systems. What feature do they have that really improves the final product or its delivery time?

12

I thought Team System utilzies VSS 2005 as its backend for source control.

It is actually based on SQL Server 2005. There are web services that provide the interfaces into it, making it very extensible.

Here is a link to a detailed FAQ on TFS’s capabilities, including what “features” from VSS were left out, how to Migrate from several competitive products and more:
http://msdn.microsoft.com/vstudio/teamsystem/support/faqs/foundation_techfaq/default.aspx#version

Also, check out Brian Harry’s blog for cool info and updates. http://blogs.msdn.com/bharry/

13

Subversion supports exclusive locks as well as non-exclusive.

@Briec: Keeping the discussion to VSS vs Non-VSS, non-exclusive locks is a key feature for improving delivery time.

You might say a shared file store gives you that, true. But it doesn’t give you automatic conflict detection when checking files back into the central repository, which is more important than automatic merge.

14

We almost switched to Team System, but the SourceSafe-style checkout-edit-checkin working style killed the deal. We had switched from SourceSafe to Subversion a year before and absolutely loved the edit-merge-commit working style. I had an email exchange with Brian Harry about this where I asked for clarification on his statement that “we designed it so we could support edit-merge-commit in v2”, and discovered that it was nothing more than “automatic checkout from within the tool”, not true edit-merge-commit, since files are read-only on the file system and they don’t provide file system hooks like Tortoise does.

The problem is that Microsoft’s internal SourceDepot has the checkout-edit-checkin working style, so they see no need to support edit-merge-commit when they’re dogfooding it. I think that being locked into server-managed checkout-edit-checkin under the hood is one of the fundamentally broken by-design parts of SourceSafe that has carried forward to Team System.

15

Bryan Zug: Check out Alienbrain (http://www.alienbrain.com/), an SCM built for multimedia production from the ground up. Good integration with media applications, but also development tools such as Visual Studio.

16

not true edit-merge-commit, since files are read-only on the file system and they don’t provide file system hooks like Tortoise does.

Oran, this isn’t technically correct. Team System is absolutely an edit-merge-commit system at its very core. That is the default setting.

What you’re looking for a source control system that lets you edit directly from the filesystem. Team System doesn’t really do this; you have to signify intent to edit to the server through either the IDE or the command-line tool (TF.exe). You can’t just plow into the files on disk and start changing them without letting the server know what you’re doing.

The Team System model, for better or worse, is an always-connected one. It’s possible to work offline, but it takes some workarounds:

http://blogs.vertigosoftware.com/teamsystem/archive/2006/07/03/2984.aspx

17

Not having to checkout files (signify intent to edit in some way) before you start working is one of the real strength of, for instance, Subversion in my opinion. I don’t think anyone who has tried that model would like to go back to an SCM that keep files read-only until checked out. Allowing multiple, concurrent checkouts is NOT the same thing as always keeping the files writable. It’s a huge difference.

18

Tortoise SVN is a good alternative for VSS2005. Only problem with SVN is you better have a really fast hard disk and lots of memory because your machine will bog between gets, builds in VS2005, and commits.

Right now I have completed an update from our repository and I am waiting to get control back to devenv.exe from TSVNCache.exe which is currently throttling the cpu at 65-100% :(.

19

C-J: my sentiments exactly.

Jeff: in my mind “checkout” == “any source-control-specific-steps I have to take before I can edit a file that’s already on my hard drive.” Even if the IDE does this automatically for me, I hate the little delay when I start typing. And this only works in the IDE. I have to jump through all sorts of hoops if I want to make a change with Notepad.

Team System doesn’t do enough client-side tracking to provide a classic edit-merge-commit working style. Your link mentions that you should avoid off-line renames which I’m guessing is due to this not being tracked client-side.

There are a number of other issues I found with Team System when I researched it back in December. Subversion tracks changes at the directory level while VSTS only tracks per-file. You can’t exclude directories from source control in VSTS. All root VSTS folders must correspond to Team Projects. You can’t create a “simple” source-controlled folder in VSTS. VSTS doesn’t let you merge between unrelated branches, only parent-child branches. VSTS doesn’t have “blame/praise”.

In Subversion, the client keeps track of what files and versions you have. In VSTS, the server keeps track of what files and versions you have. This causes problems when moving stuff around on the client, but can speed up updates in “workspaces containing tens of thousands of files.”

In Subversion, “move” is implemented as “add with history and delete”. “Move” in VSTS is a thinly disguised alias for Rename. You also can only move one file at a time in VSTS.

Unlike Subversion, I’m guessing you can’t efficiently “switch” local files between branches, reusing the pre-existing client-side files, only transmitting and changing the diffs.

At the end of my post is Brian Harry’s response to my request for true edit-merge-commit. Notice that his goal is to stay firmly in the “checkout” camp even in v2 and convert people to that style by removing as many of the speed bumps as possible. I honestly don’t see what value those speed bumps add (even when minimized), other than seeing who has which files “checked out”, which can never be 100% accurate due to offline checkouts.

Brian’s email:

Edit-merge-commit is a model that we want to support and will some day. Unfortunately we were not able to get it implemented for V1. I don’t know what to tell you there. I’m always interested to hear from people who prefer edit-merge-commit. It seems to having explicit checkouts is better (if you can mitigate the costs and deal with the offline issue). We haven’t done everything in V1 yet to make the checkout model we have great (unfortunately). We have plans in V2 to make checkouts work while you are off line and to make it asynchronous. This way it should be transparent and appear as if you are using edit-merge-commit but have the advantages of checkouts - including enforcing exclusive checkouts of unmergable files, allowing me to easily see all files that I have modified, and allowing me to inspect files other people are working on. I think when we do this we’ll convert many people to checkouts but only time will tell.

I wish I had a better answer for you right now but I don’t :frowning:

Brian

20

haw man, source control and branch/merges not necessary… that’s crazy.

on some projects, we have groups of one or more developers working in their own branches, protected and protecting the rest of the team. This allows developers to check in often, get the source code in the system in small bites, which are build nightly and automated-tested.

We can also narrow down very quickly what project introduce a regression by comparing automated tests on two different branches.

We have migration of compiler, port 64-bit, etc, all done in separate branches and then merged in.

We do EVERYTHING with automatic merge in ClearCase. There is only ever a problem when two users checked in the same few lines of code, and ClearCase warns us of this.

We absolutely REQUIRE branches to make incremental patches for different clients, then have these merged in with other patches and versions. We absolutely REQUIRE branches to produce different products from the same code base, with different release dates and therefore different code freeze, without interrupting developement.

We have only one guys taking care of the build for all of this, merges and bullds are all automated with scripts, and spitting out 3 to 10 different builds of the application daily…

mind you, there are a couple of people taking care of ClearCase, the thing really seems to be a best. I trust it with my life, however. Too bad the VC++ plug in now sucks since either the Rationnal or IBM aquisition…