Version control system software developed by CollabNet in 2000 is known as Subversion (SVN). This software keeps track of all work and related changes in a set of files, and permits several developers, usually separated in space and/or time to pool resources. It is broadly employed to retain current and historical versions of files such as source code, web pages, and documentation. It’s a well-known replacement for CVS (Concurrent Versions System).
1. Commits are true atomic operations. Interrupted commit operations do not cause repository inconsistency or corruption.
2. Renamed/copied/moved/removed files retain full revision history.
3. Directories, renames, and file metadata (but not timestamps) are versioned. Entire directory trees can be moved around and/or copied very quickly, and retain full revision history.
4. Versioning of symbolic links.
5. Native support for binary files, with space-efficient binary-diff storage.
6. Apache HTTP Server as network server, WebDAV/DeltaV for protocol. There is also an independent server process that uses a custom protocol over TCP/IP.
7. Branching and tagging are cheap operations, independent of file size, though Subversion itself does not distinguish between a tag, a branch, and a directory.
8. Natively client/server, layered library design.
9. Client/server protocol sends diffs in both directions.
10. Costs are proportional to change size, not data size.
11. Parsable output, including XML log output.
12. Open source licensed — “CollabNet/Tigris.org Apache-style license”.
13. Internationalized program messages.
14. File locking for unmergeable files (“reserved checkouts”).
15. Path-based authorization.
16. PHP, Python, Perl, and Java language bindings.
17. Full MIME support – the MIME Type of each file can be viewed or changed, with the software knowing which MIME types can have their differences from previous versions shown.
Subversion, which is actually a repository manager, offers two types of repository storage:
- FSFS (Fast Secure File System): Due to less logging, FSFS operates quicker on directories with a large number of files and occupies less disk space.
- Berkeley DB: Usage of Berkeley DB is somewhat limited because this type of repository leads to corruption and data loss when a program accessing database crashes or gets terminated forcibly. One can use it safely only on the dedicated server and by a single server process functioning as lone user. Tools available for Berkeley DB repository recovery aren’t completely dependable; hence frequent repository backups are required.
A Subversion repository is somewhat compact since files are stored as links to the most recent changes. The Subversion filesystem can be described as “three dimensional”. Apart from the two dimensions of a standard directory tree (e.g., tree view), the Subversion filesystem’s third dimension is revisions. All revisions in a Subversion filesystem have their own roots. These roots are then utilized to get contents at that revision. The storage space occupied is proportional to the number of changes made and not to the number of revisions. The Subversion filesystem makes use of transactions to keep changes atomic. A transaction, which is actually a long-lived filesystem object, is initiated from a specified revision of the filesystem. A client does not need to commit or abort a transaction itself; rather it can also begin a transaction, exit, and then can re-open the transaction and continue using it. The transaction has its own root, on which modifications are done. It is then either committed and becomes the latest revision, or is aborted. Several clients can access the same transaction and collaborate on an atomic change.
Major Subversion limitations include:
1. Currently, Subversion only allows directory access control and lacks more granular file access control which restricts the use of Subversion in projects where directories are not structured to address functional separation among various objects. For instance, mostly directories like lib, src, bin do not address security and access control.
2. Another trouble in Subversion is the implementation of the file and directory rename operation. Subversion currently implements the renaming of files and directories as a ‘copy’ to the new name followed by a ‘delete’ of the old name. Only the names are changed, all data relating to the edit history remains the same, and Subversion will still use the old name in older revisions of the “tree”. However, Subversion may be confused when files are modified and moved in the same commit. This can also cause problems when a move conflicts with edits made elsewhere.
3. Existing version of Subversion lacks some repository administration and management features. For instance, Subversion does not have built-in mechanism to permanently remove all historical records of certain data being in the repository.
4. Subversion stores supplementary copies of data on the local machine, which can pose a problem for very large projects or files, or if developers are working on multiple branches simultaneously. These .svn directories on the client side can become corrupted if misguided by user activity.