| Subversion (software) |
Article Index for Subversion |
Website Links For Subversion |
Information AboutSubversion (software) |
In computing, Subversion ('''SVN''') is a Version Control system (VCS) initiated in 2000 by CollabNet Inc. It allows users to keep track of changes made over time to any type of electronic data. Typical uses are versioning source code, web pages or design documents. Use of Subversion as a VCS has surpassed that of , KDE , GNOME , Freepascal , GCC , Python , Samba , Mono and many others. SourceForge.net and Tigris.org also provide Subversion hosting for their open source projects, Google Code and BountySource systems use it exclusively. Subversion is also finding adoption in the corporate world. In the report “The Forrester Wave™: Software Change and Configuration Management, Q2 2007” , Subversion was recognized as the sole leader in the Standalone Software Configuration Management (SCM) category and strong performer in the Software Configuration and Change Management (SCCM) category. Released under the Apache License , Subversion is Free And Open Source Software . FEATURES
Repository access As of version 1.4, Subversion repositories can be accessed by the following means:
All three means can access both FSFS and Berkeley DB repositories. LAYERS Subversion is composed internally of several libraries arranged as layers. Each performs a specific task and allows developers to create their own tools at the desired level of complexity and specificity. ; Fs : The lowest level; it implements the versioned filesystem which stores the user data. ; Repos : Concerned with the repository built up around the filesystem. It has many helper functions and handles the various 'hooks' that a repository may have, e.g. scripts that are run when an action is performed. Together, Fs and Repos constitute the "filesystem interface". ; mod_dav_svn : Provides WebDAV /DeltaV access through Apache 2. ; Ra : Handles "repository access", both local and remote. From this point on, repositories are referred to using URLs, i.e. file:///path/ for local access, ; Client, Wc : The highest level. It abstracts repository access and provides common client tasks, e.g authenticating the user, or comparing versions. The Wc library is used by Client to manage the local working copy. FILESYSTEM The Subversion filesystem is described as a "three dimensional" filesystem. Since most representations of a directory tree (e.g Tree View ) are two dimensional, the added dimension is that of revisions. Each revision in a Subversion filesystem has its own '' Root '', which is used to access contents at that revision. Files are stored as links to the most recent change; thus a Subversion repository is quite compact. The storage space used is proportional to the number of changes made, not to the number of revisions. The Subversion filesystem uses transactions to keep changes Atomic . A transaction is begun from a specified revision of the filesystem, not necessarily the latest. The transaction has its own ''root'', on which changes are made. It is then either committed and becomes the latest revision, or is aborted. The transaction is actually a long-lived filesystem object; 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. Multiple clients can access the same transaction and work together on an atomic change. PROPERTIES One important feature of the Subversion filesystem is properties, simple ''name''=''value'' pairs of text. Properties are used in two different places in the Subversion filesystem. The first is on filesystem entries (i.e., files and directories). These are versioned just like other changes to the filesystem. Users can add any property they wish, and the Subversion client uses a set of properties, which it prefixes with 'svn:'. ; svn:executable : Makes files on Unix -hosted working copies executable. ; svn:mime-type : Stores the MIME type of a file. Affects the handling of diffs and merging. ; svn:ignore : A list of filename patterns to ignore in a directory. Similar to CVS 's .cvsignore file. ; svn:keywords : A list of ''keywords'' to substitute into a file when changes are made. The keywords must also be referenced in the file as $. This is used to maintain certain information (e.g date of last change, revision number) in a file without human intervention. ; svn:eol-style : Makes the client convert End-of-line characters in text files. Used when the working copy is needed with a specific EOL style. "native" is commonly used, so that EOL's match the users OS EOL style. Repositories may require this property on all files to prevent inconsistent line endings, which can be a problem in itself. ; svn:externals : Allows parts of other repositories to be automatically checked-out into a sub-directory. ; svn:needs-lock : Specifies that a file is to be checked out with file permissions set to read-only. This is designed to be used with the locking mechanism. The read-only permission is a reminder to obtain a lock before modifying the file: obtaining a lock makes the file writable, and releasing the lock makes it read-only again. Locks are only enforced during a commit operation. Locks can be used without setting this property. However, that is not recommended, because it introduces the risk of someone modifying a locked file; they will only discover it has been locked when their commit fails. ; svn:special : This property isn't meant to be set or modified directly by users. Currently only used for having Symbolic Link s in the repository. When a symbolic link is added to the repository, a file containing the link target is created with this property set. When a Unix-like system checks out this file, the client converts it to a symbolic link. The second place in Subversion where properties are used is on revisions themselves. Like the above properties on filesystem entries the names are completely arbitrary, with the Subversion client using certain properties prefixed with 'svn:'. However, these properties are not versioned and can be changed later. ; svn:date : The date and time stamp of when the revision was made. ; svn:author : The name of the user that submitted the change(s). ; svn:log : The user-supplied description of the change(s). BRANCHING AND TAGGING Subversion uses the interfile branching model from and tags. A new branch or tag is created with the 'svn copy' command, which should be used in place of the native operating system mechanism. Subversion does not create an entire new file in the repository with its copy. Instead, the old and new files are linked together internally and the history is preserved for both. The copied files only take up a little extra room in the repository because Subversion only saves the differences from the original files. The minimal layout recommended for a ''project'' repository looks similar to this with branches and tags added:
On larger projects, the above structure is repeated throughout the repository at different levels in the project tree. The paths listed under tags are snapshots of the '''trunk''' on the same repository level, and they are commonly named after the release dates or version related to snapshot. The paths under tags are generally for read-only access once created.
The paths listed under branches are commonly named after subsequent minor versions (or subversions) of the current repository level, given names of certain features, or have cross reference information. Branches can form more repository levels and also have a trunk node. For example, the layout as shown above is repeated as if the branches form new sub-projects of the project.
The tags directory contains snapshots of the trunk at particular , usually major releases or perhaps prior to a major departure in development. The trunk directory holds the head version for each branch level. The branches directory holds versions (or subversions) of the project that a developer or group of developers may be working on. Each '''trunk''' path is in alignment to merge changes with the '''trunk''' in the level above each other. The changes can be merged into the trunk above or into other branches. This not only allows changes to be checked into the repository and shared separately; it also allows implementations models to be distributed across the repository and provides access to previous versions for maintenance. It is not intended for someone to check-out the entire ''project'' tree; instead, they need only to check-out one of the trunk paths or one of the tagged snapshots. The tags were made by svn mechanisms, like the usual command line to copy a trunk to a new path: :svn copy trunk tags/my-new-snapshot Likewise, branch creation only requires a few extra steps to setup a new layout: :svn mkdir branches/my-new-branch :svn mkdir branches/my-new-branch/tags :svn mkdir branches/my-new-branch/branches :svn copy trunk branches/my-new-branch/trunk All the files in each branch maintain the history of the file up to the point of the copy, plus any changes made since. Changes can be 'merged' back into the trunk or between branches. To Subversion, the only difference between tags and branches is that changes should not be checked into the tagged versions. Due to the differencing algorithm, creating a tag or a branch takes very little additional space in the repository. CURRENT ISSUES A known issue in Subversion is the implementation of the file and directory rename operation. Subversion currently implements the renaming of files and directories as a copy and a delete: a 'copy' to the new name followed by a 'delete' of the old name. The effect of this is that code changes are inadvertently lost under multiple merge related scenarios. Such code loss can span one or many files and can be difficult to detect and correct. This is documented in the Subversion issue database.http://subversion.tigris.org/issues/show_bug.cgi?id=898 Subversion currently lacks some repository administration and management features. For instance, it is sometimes desired to make permanent edits to the repository to permanently remove all historical records of certain data being in the repository. Subversion does not have built-in support to allow this to be done simply. The standard user-level interface allows files and directories to be moved or deleted, but earlier versions of the repository can always be retrieved. The current solution to this sort of problem involves 'dumping' the repository, editing the resulting (possibly large) text file, and then recreating the repository. For simple renaming or removal of files this is fairly straight-forward, but other alterations can be more complex and hence error-prone.http://subversion.tigris.org/issues/show_bug.cgi?id=516 Subversion requires the use of extra .svn directories which can become mangled. The SVK project aims to improve this situation. RELEASES See Also: Software which uses Subversion CollabNet is still involved with Subversion but the project is run as an independent open source community. The home of Subversion is on Tigris.org , an open source community dedicated to software engineering tools. The Subversion open source community does not provide binaries but these can be downloaded from volunteers and from CollabNet, the initiator of the Subversion open source project. While the Subversion project does not include an official Graphical User Interface (GUI) for use with Subversion, a number of different GUIs have been developed, along with a wide variety of additional ancillary software. SEE ALSO
NOTES REFERENCES
EXTERNAL LINKS
|
|
|