Apache Subversion

Content sourced from Wikipedia, licensed under CC BY-SA 3.0.

Apache Subversion (SVN) is an open-source, centralized version control system under the Apache License. It helps teams manage current and historical versions of files such as source code, documentation, and web pages. SVN was created in 2000 by CollabNet as a more reliable successor to CVS and became an Apache top-level project in 2010. It has been widely used by projects like the Apache Software Foundation, FreeBSD, GCC, and others.

How Subversion stores data
- Subversion supports two main repository backends. The older Berkeley DB backend was deprecated in version 1.8. A newer storage system called FSFS was introduced in 2004 and became the default for new repositories in 1.2 because it is faster and uses less disk space. A newer experimental backend called FSX has been worked on to address some limitations of FSFS.
- Subversion stores data in revisions. Each revision has its own root, and files are stored as links to the most recent change, making repositories relatively compact.
- Changes are made inside transactions. You begin a transaction on a revision, make changes, and then either commit (creating a new revision) or abort. A transaction can be long-lived and opened again later if needed.
- You can attach simple name=value properties to files, directories, and revisions. Some properties are built-in and use the svn: prefix; others are custom.

Branching, tagging and merging
- Subversion uses the same mechanism for branches and tags: copies inside the repository. A branch or tag is created with svn copy, preserving history and taking little extra space.
- You can merge changes between branches or back into the trunk.

Naming and some quirks
- Renaming in Subversion is implemented as a copy to a new name followed by a delete of the old name. This preserves history, but can cause confusion when conflicts arise during edits or merges.
- Subversion is centralized, so it’s designed around a single shared repository rather than multiple copies like distributed systems.

Limitations and quirks
- Historically, Subversion did not provide an easy way to permanently remove data from history; large projects or many branches could consume more disk space.
- Client-side working copies used to store data in .svn folders, which could be fragile; since 1.7, Subversion uses a single centralized .svn folder per working area to reduce problems.
- Subversion does not automatically record file modification times in the same way as the repository; checked-out files show the current date, while checked-in files get the check-in date. Third-party tools can help preserve timestamps if needed.
- The system uses a centralized revision model, which some developers see as a drawback compared to distributed version control systems like Git.

Access and ecosystem
- Subversion clients can work with both FSFS and Berkeley DB repositories. Newer clients and servers add features and performance improvements while maintaining backward compatibility with older versions.
- There is no official binary distribution or GUI from the project itself; a variety of third-party tools and GUIs exist, along with programmers’ APIs (such as a Java API).

History and milestones
- Subversion was created by CollabNet in 2000 to fix bugs and missing features in CVS.
- Version 1.0 was released in 2004.
- It entered the Apache Incubator in 2009 and became a top-level Apache project in 2010.
- The project has seen ongoing development, including performance improvements, better copying and moving between branches, and new features, with community and corporate sponsorship contributing to its evolution.

Today, Subversion remains a widely used tool for many teams and projects, especially where a centralized model fits their workflow, even as newer distributed systems have become popular for other kinds of development.