Source Control Systems

Let me start this by noting that I have never seen nor used Perforce, but I understand
from those on my team who have that it is basically one kick-butt source control
system.  That being said, how kick-butt can a source control system truly be? 
Isn’t it somewhat akin to saying, “Did you see that muffler on that car?  That
was a real kick-butt muffler.”  I mean, is it really possible to get that excited
over these things?

While watching this discussion, it occurred to me recently that my team has ready
access to at least 4 source control systems that do not cost a dime (unlike the $800
per seat Perforce cost).

1. CVS using Tortoise and/or Win CVS (open source)

2. SVN using Tortoise and/or RapidSVN (open source)

3. VSS through our MSDN licensing

4. Team System Beta through our MSDN licensing

With all of these options, why would we ( a small to mid-size development shop ) actually
shell out money for one of these things?  I cannot imagine.  I understand
that the Perforce client offers much better branching and merging capabilities
than the Tortoise or other open source options, but can’t the need for that functionality
be mitigated by the approach that you take to your source control structure?

Let’s look at 2 popular ways to fix a bug.

Option 1 – Trunk is God

1. Make a branch off of the trunk.
   • You may want to send an order to your build master to build your trunk.
2. Check out from the branch

3. Make your changes to fix the bug.

4. Compile, pass tests

5. Commit changes

6. Merge the trunk to your branch, there may have been changes.

7. Compile, pass tests

8. Merge to the branch to the trunk.

9. It should build and pass tests

10. Delete branch
    • You might need to tell your build master that the branch is gone

Option 2 – Trunk is the Development Code

1. Check out from the trunk

2. Make your changes to fix the bug.

3. Compile, pass tests

4. Do an update, there may have been changes

5. Compile, pass tests

6. Commit changes.  An archival branch (or label or something) is created automatically.

7. It should build and pass tests

In Option 1, we branched once and merged twice.  In Option 2, we were just careful
by performing an update of our local copy before committing.  The TortoiseSVN
client does this for us automatically, so really we just coded.

Am I missing some huge advantage to Option 1?  At this point it seems that Option
2 is less overhead and mitigates the need for intuitive branching and merging capabilities
to be built into the source control client.  This means that one of those freebie
systems might be just the ticket.

I would love comments on this one.  What am I missing?