소프트웨어 개발자들에게 가장 힘든 부분중의 하나가 소스코드 관리일 것입니다.
업체의 요청에따라 하루가 다르게 수정되고 추가되는 코드를 관리하기가 절대로 쉬운일은 아니지요.
이러한 개발자들의 불편사항을 해결하기 위해 나온 시스템이 '버전관리시스템(Version Control System)' 입니다.
버전관리 시스템중에서도 가장 보편적으로 사용하는 프로그램이 'Subversion' 이라는 버전관리 프로그램입니다.
CVS의 대부분의 특징
Subversion은 더 나은 CVS를 위함이므로, 대부분의 CVS의 특징을 지니고 있습니다. 일반적으로, 각각의 Subversion 인터페이스는 CVS와 유사합니다.
Directories, renames, and file meta-data are versioned.
Lack of these features is one of the most common complaints against CVS. Subversion versions not only file contents and file existence, but also directories, copies, and renames. It also allows arbitrary metadata ("properties") to be versioned along with any file or directory, and provides a mechanism for versioning the `execute' permission flag on files.
Commits are truly atomic.
No part of a commit takes effect until the entire commit has succeeded. Revision numbers are per-commit, not per-file; log messages are attached to the revision, not stored redundantly as in CVS.
Apache network server option, with WebDAV/DeltaV protocol.
Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, wire compression, and basic repository browsing.
Standalone server option.
Subversion also offers a standalone server option using a custom protocol (not everyone wants to run Apache 2.x). The standalone server can run as an inetd service, or in daemon mode, and offers basic authentication and authorization. It can also be tunnelled over ssh.
Branching and tagging are cheap (constant time) operations
There is no reason for these operations to be expensive, so they aren't.
Branches and tags are both implemented in terms of an underlying "copy" operation. A copy takes up a small, constant amount of space. Any copy is a tag; and if you start committing on a copy, then it's a branch as well. (This does away with CVS's "branch-point tagging", by removing the distinction that made branch-point tags necessary in the first place.)
Natively client/server, layered library design
Subversion is designed to be client/server from the beginning; thus avoiding some of the maintenance problems which have plagued CVS. The code is structured as a set of modules with well-defined interfaces, designed to be called by other applications.
Client/server protocol sends diffs in both directions
The network protocol uses bandwidth efficiently by transmitting diffs in both directions whenever possible (CVS sends diffs from server to client, but not client to server).
Costs are proportional to change size, not data size
In general, the time required for a Subversion operation is proportional to the size of the changes resulting from that operation, not to the absolute size of the project in which the changes are taking place. This is a property of the Subversion repository model.
Choice of database or plain-file repository implementations
Repositories can be created with either an embedded database back-end (BerkeleyDB) or with normal flat-file back-end, which uses a custom format.
Versioning of symbolic links
Unix users can place symbolic links under version control. The links are recreated in Unix working copies, but not in win32 working copies.
Efficient handling of binary files
Subversion is equally efficient on binary as on text files, because it uses a binary diffing algorithm to transmit and store successive revisions.
All output of the Subversion command-line client is carefully designed to be both human readable and automatically parseable; scriptability is a high priority.
Subversion uses gettext() to display translated error, informational, and help messages, based on current locale settings.
Subversion supplies a utility, svnsync for synchronizing (via either push or pull) a read-only slave repository with a master repository.
Subversion 홈페이지 : http://subversion.tigris.org