Apache Subversion

Subversion

Dosya:Subversion.png
Geliştirici(ler)	Komünite ve CollabNet, Elego, VisualSVN ve WANdisco'dan geliştiriciler
İlk yayınlanma	Şablon:İnitial-release
Güncel sürüm	1.14.5  8 Aralık 2024
Geliştirme durumu	Aktif
Programlama dili	C
İşletim sistemi	Cross-platform
Tür	Sürüm Kontrol
Lisans	Apache Lisansı
Resmî sitesi	http://subversion.apache.org/
Kod deposu	svn.apache.org/repos/asf/subversion/trunk/

Yazılım geliştirmede Apache Subversion (eski adıyla Subversion, 2000 yılında CollabNet firması tarafından başlatılan ve desteklenen bir sürüm kontrol sistemidir. Yazılım geliştiricileri Subversion'ı kaynak kodu, ağ sayfaları veya belgelendirme gibi dosyaların güncel ve geçmiş tüm değişikliklerini tutmak için kullanırlar. Amacı yaygın olarak kullanılan Concurrent Versions System (CVS)'in olabildiğince uyumlu bir ardılı olmaktır.

Açık kaynak komünitesi Subversion'ı yaygın olarak kullanmıştır: örneğin Apache Software Foundation projelerinde, Free Pascak, FreeBSD, GCC, Django, Ruby, Mono, SourceForge, ExtJS, Tigris.org, PHP ve MediaWiki. Google Code açık kaynak proje barındırmalarında Subversion desteği de vermektedir. CodePlex diğer istemcilere olduğu kadar Subversion erişimi de sağlamaktadır.

İş dünyası da Subversion kullanımı kabul etmeye başlamıştır. Forrester Research tarafından 2007 yılında hazırlanan bir rapora göre Tekbaşına Yazılım Konfigürasyonu Yönetimi (SCM) kategorisinde Subversion'ı lider ve Yazılım Konfigürasyonu ve Değişiklik Yönetimi (SCCM) alanında da güçlü bir oyuncu gösterilmiştir.

Subversion Apache Lisansını kullanmaktadır ve açık kaynak kodludur.

Tarihçe

Subversion projesi 2000 yılında CollabNet adlı firma tarafından, CVS adlı sürüm kontrol sisteminin sahip olmadığı bazı özellikleri sağlayarak yerini almak üzere açık kaynaklı bir proje olarak başlatıldı. 2001 yılına gelindiğinde kendi kaynak kodunu barındırabilecek duruma gelen Subversion, Kasım 2009'da Apache Incubator projesine dahil edilerek tepe seviye Apache projesi haline gelmesinin başlangıcı olarak gösterildi. ve 17 Şubat 2010 tarihinde tepe seviye Apache projesi haline geldi.

Özellikleri

• Commits as true atomic operations (interrupted commit operations would otherwise cause repository inconsistency or corruption).
• Renamed/copied/moved/removed files retain full revision history.
• The system maintains versioning for directories, renames, and file metadata (but not for timestamps). Users can move and/or copy entire directory-trees very quickly, while retaining full revision history.
• Versioning of symbolic links.
• Native support for binary files, with space-efficient binary-diff storage.
• Apache HTTP Server as network server, WebDAV/Delta-V for protocol. There is also an independent server process called svnserve that uses a custom protocol over TCP/IP.
• Branching and tagging as cheap operations, independent of file size (though Subversion itself does not distinguish between a tag, a branch, and a directory)
• Natively client–server, layered library design.
• Client/server protocol sends diffs in both directions.
• Costs proportional to change size, not to data size.
• Parsable output, including XML log output.
• Open source licensed — Apache License in the projected 1.7 release; prior versions use a derivative of the Apache Software License, v1.1
• Internationalized program messages.
• File locking for unmergeable files ("reserved checkouts").
• Path-based authorization.
• Language bindings for C#, PHP, Python, Perl, and Java.
• Full MIME support - users can view or change the MIME type of each file, with the software knowing which MIME types can have their differences from previous versions shown.

Depo türleri

Subversion offers two types of repository storage — FSFS and Berkeley DB.

FSFS

FSFS works faster on directories with a large number of files and takes less disk space, due to less logging.

Berkeley DB

Subversion has some limitations with Berkeley DB usage leading to repository corruption and data loss when a program that accesses the database crashes or terminates forcibly. When using Berkeley DB repository, the only way to use it safely is on the dedicated server and by a single server process running as one user, according to Version Control with Subversion. Existing tools for Berkeley DB repository recovery aren't completely reliable, so system administrators need to make frequent repository backups.

Depo erişimi

Ana madde: Comparison of Subversion clients

Access to Subversion repositories can take place by the following means:

1. Local filesystem or network filesystem, accessed by client directly. This mode uses the file:///path access scheme.
2. WebDAV/Delta-V (over http or https) using the mod_dav_svn module for Apache 2. This mode uses the http://host/path access scheme or https://host/path for secure connections using ssl.
3. Custom "svn" protocol (default port 3690), using plain text or over SSH. This mode uses either the svn://host/path access scheme for unencrypted transport or svn+ssh://host/path scheme for tunneling over ssh.

All three means can access both FSFS and Berkeley DB repositories.

Any 1.x version of a client can work with any 1.x server. Newer clients and servers have additional features and performance capabilities, but have fallback support for older clients/servers.

Katmanlar

Internally, a Subversion system comprises 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 run when an action is performed. Together, Fs and Repos constitute the "filesystem interface".

mod_dav_svn

Provides WebDAV/Delta-V access through Apache 2.

Ra

Handles "repository access", both local and remote. From this point on, repositories are referred to using URLs, e.g.

• file:///path/ for local access,
• http://host/path/ or https://host/path/ for WebDAV access, or
• svn://host/path/ or svn+ssh://host/path/ for the SVN protocol.

Client, Wc

The highest level. It abstracts repository access and provides common client tasks, such as authenticating users or comparing versions. Subversion clients use the Wc library to manage the local working copy.

Dosya sistemi

One can view the Subversion filesystem as "two-dimensional". Two coordinates are used to unambiguously address filesystem items:

• Path (regular path of Unix-like OS filesystem)
• Revision

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 system consumes storage space proportional to the number of changes made, not to the number of revisions.

The Subversion filesystem uses transactions to keep changes atomic. A transaction operates on 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.

Özellikler

One important feature of the Subversion filesystem is properties: simple name=value pairs of text. Properties occur 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 file itself must also reference the keywords as $keyword$ or $keyword:...$. This is used to maintain certain information (e.g., author, date of last change, revision number) in a file without human intervention.
The keyword substitution mechanism originates from rcs and from cvs.

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 user's OS EOL style. Repositories may require this property on all files to prevent inconsistent line endings, which can cause 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 for use with the locking mechanism. The read-only permission reminds one 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. (2010 (2010) itibarıyla) only used for having symbolic links 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.

svn:mergeinfo

Used to track merge data (revision numbers) in Subversion 1.5 (or later). This property is automatically maintained by the merge command, and it is not recommended to change its value manually.

Subversion also uses properties 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 a revision

svn:author

the name of the user that submitted the change(s)

svn:log

the user-supplied description of the change(s)

Dallanma ve Etiketleme

Subversion uses the inter-file branching model from Perforce to handle branches and tags. A branch is a separate line of development. Tagging involves creating a snapshot of the repository's content, which, unlike a branch, is not expected to change in the future.

The system sets up a new branch or tag by using the 'svn copy' command, which should be used in place of the native operating system mechanism. Subversion does not create an entire new file version in the repository with its copy. Instead, the old and new versions are linked together internally and the history is preserved for both. The copied versions take up only a little extra room in the repository because Subversion saves only the differences from the original versions.

All the versions in each branch maintain the history of the file up to the point of the copy, plus any changes made since. One can "merge" changes 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.

Visualization of a very simple Subversion project

Mevcut sınırlamalar ve problemler

Release 1.6.* of Subversion only allows directory access control and lacks more granular file access control. That problem dramatically restricts the use of Subversion in projects where directories are not structured to address the functional separation among various objects. For example, directories like lib, src, bin do not address security and access control in most cases.

A known problem in Subversion affects the implementation of the file and directory rename operation. (2010 (2010) itibarıyla), Subversion 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 change, 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 become confused when files are modified and moved in the same commit. This can also cause problems when a move conflicts with edits made elsewhere, for example during merging branches. The Subversion 1.5 release addressed some of these scenarios while others remain problematic.

(2010 (2010) itibarıyla) Subversion lacks some repository-administration and -management features. For instance, someone may wish to edit the repository to permanently remove all historical records of certain data. Subversion does not have built-in support to achieve this simply.

Subversion stores additional copies of data on the local machine, which can become an issue with very large projects or files, or if developers work on multiple branches simultaneously. These .svn directories on the client side can become corrupted by ill-advised user activity. The "svn cleanup" command helps in case of internal lock caused by unfinished operation.

Subversion does not store the modification times of files. As such, a file checked out of a subversion repository will have the 'current' date (instead of the modification time in the repository), and a file checked into the repository will have the date of the check-in (instead of the modification time of the file being checked in). This might not always be what is wanted.

Subversion does not use a distributed revision control model. Ben Collins-Sussman, one of the designers of Subversion, believes a centralised model would help prevent "insecure programmers" from hiding their work from other team members.

While Subversion stores filenames as Unicode, it does not specify if precomposition or decomposition is used for certain accented characters (such as é). Thus, files added in SVN clients running on some operating systems (such as OS X) use decomposition encoding, while clients running on other operating systems (such as Linux) use precomposition encoding, with the consequence that those accented characters do not display correctly if the local SVN client is not using the same encoding as the client used to add the files.

By design, the svn log command is always recursive: trying to access the history of a directory systematically pulls out the history of its entire hierarchy. A workaround is not to use the command line but use a sophisticated SVN client with filtering capabilities.

Subversion etiketleri

This subsection focuses on tags but parts of it also apply to branches.

Revision numbers are difficult to remember in any version-control system. For this reason most systems offer symbolic tags as user-friendly references to them. Subversion does not have such a feature and what its documentation recommends to use instead is very different in nature. Instead of implementing tags as references to points in history, Subversion recommends taking snapshots and storing them in a well-known subdirectory ("tags/") in the space of the repository tree.

This history-to-space projection causes at least two problems:

1. Once a snapshot has been taken, the system does not remember which revision it came from. This is the difference between a copy and a reference. This makes some operations less convenient and others impossible. For instance a naive svn diff -r tag1:tag2 myfile does not work; it is slightly more complicated than that to achieve. Other operations like for instance svn log -r tag1:tag2 myfile are just impossible.

2. When two (ideally independent) object types live in the repository tree, a "fight to the top" can ensue. In other words it is often difficult to decide at which level to create the "tags/" subdirectory:

trunk/componentfoo/ /componentbar/ tags/1.1/componentfoo/ /componentbar/

or

componentfoo/trunk/ /tags/1.1/ componentbar/trunk/ /tags/1.1/

To address such problems, posters on the Subversion mailing lists have suggested a new feature called "labels". SVN labels would more closely resemble the "tags" of other systems such as CVS or git. (2010 (2010) itibarıyla) this suggestion has not progressed.

Geliştirme ve uygulama

Ana madde: Software that uses Subversion

CollabNet has continued its involvement with Subversion, but the project runs as an independent open source community. In November 2009 the project was accepted into the Apache Incubator, aiming to become part of the Apache Software Foundation's efforts. Since March 2010, the project is formally known as Apache Subversion, being a part of the Apache Top-Level Projects.

In October 2009 WANdisco announced the hiring of core Subversion committers as the company moved to become a major corporate sponsor of the project. This included Hyrum Wright, president of the Subversion Corporation and release manager for the Subversion project since early 2008, who joined the company to lead its open source team.

The Subversion open-source community does not provide binaries, but potential users can download such from volunteers, from CollabNet, the initiator of the Subversion project or WANdisco. While the Subversion project does not include an official graphical user interface (GUI) for use with Subversion, third parties have developed a number of different GUIs, along with a wide variety of additional ancillary software.

Geliştirme Yol Haritası

The Subversion committers normally have at least one or two new features under active development at any one time. As of January 2010 the major goals for the next version of Subversion included a streamlined HTTP transport to improve performance and a rewritten working-copy library.

Other work in progress includes SubversionJ (a JAVA API) and implementation of the Obliterate command, similar to that provided by Perforce. Both of these enhancements are being sponsored by WANdisco.

Ayrıca bakınız

• Sürüm kontrol yazılımlarının listesi
• Sürüm kontrol yazılımlarının karşılaştırması
• Subversion istemcilerinin karşılaştırması
• Subversion also integrates with Aba CM Enablement

Referanslar

Daha fazla okuma

• Dispelling Subversion FUD by Ben Collins-Sussman (Subversion developer), as of 2004-12-21

Dış bağlantılar

• Official Site
  • Previous official site Not all content has yet been migrated to the new official site.
• Version Control with Subversion, an O'Reilly book available for free online
• Curlie'de Subversion (DMOZ tabanlı)
• HOWTO setup Subversion for Windows with Apache (English)
• Subversion usage Tutorial
• Subversion Community Site