It’s early 2004, and if you’re a developer, you likely have a love-hate relationship with CVS. We love having version control, but we hate that it doesn't support atomic commits (if a commit fails halfway through, your repo is in a "split" state). We hate that you can't rename files without losing their history. And we hate that directories aren't versioned.
Subversion (SVN) 1.0 has arrived to save us.
"CVS Done Right"
The goal of the Subversion project was simple: create a version control system that feels like CVS but fixes its fundamental design flaws.
- Atomic Commits: A commit is all-or-nothing.
- Directory Versioning: You can track when a folder was created or deleted.
- Metadata: You can attach arbitrary properties (like "license" or "status") to files and directories.
- Efficient Branching: Branches and tags are just "cheap copies." They don't take up extra space until you change something.
# Branching in SVN is just a 'cp' command
svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a branch for my new feature"
The Architecture
SVN uses a centralized repository model, just like CVS. This makes it easy for corporate IT to manage and backup. It also introduces the "WebDAV" protocol, allowing you to browse the repository through a standard web browser.
Looking Ahead
Subversion is rapidly becoming the new standard for open-source and corporate projects alike. It’s much more robust than CVS, and the tooling (like TortoiseSVN on Windows) is fantastic.
While there is some noise about "Distributed" version control systems like BitKeeper or the new Darcs, the centralized model of SVN feels "safe" for most teams. It’s going to be the king of the hill for a long time.