I find it amazing how much corporate code is still locked down behind bars with CVS. Even though its the least useful reversion control system, its still the most widely used. Don’t get me wrong, 20 years ago CVS was a monumental invention and an absolutely necessary tool for software development teams. The problem is that it tracks files, not content, which makes it a fundamentally flawed tool to manage code.  It wasn’t until I started using Git on a regular basis that I truly understood this distinction.  Let me give my most noticeable observation after making the switch.

In CVS, once you create a file and add content into it, the two are tightly coupled for forever. The file can’t be renamed, moved, or deleted from the repository.  Future iterations, even if done on a branch, are forever burdened with this history. In Git, a file can be moved, renamed, and deleted from the repository without loosing any of the contents history.  This means, I can merge branch B with branch A and move the result into a different directory under a different filename and not loose any of the content history from branch B or A.

This simple difference allows me to iterate freely in a repository. Just today, I reorganized my entire 8 month old repository into different directories with different file names.  Why?  Because good code matures over time. A file that once only contained a data structure definition can evolve into its own thread of control, which for organizational purposes might be stored elsewhere with the other program threads. This isn’t the only improvement over CVS. Its distributed architecture and superior branch management encourages greater developer collaboration. Oh, and its fast… really fast.

Restricting your code prevents iteration which stifles improvement.

Cant learn something new?  Go into retail. Legacy humans can upgrade their firmware with 20 easy commands:
http://www.kernel.org/pub/software/scm/git/docs/everyday.html