svn

Check out a working copy from a repository

$ svn [[co|checkout]] [url/to/repository]

$ svn [[up|update]]

$ svn add [PATH]

$ svn [[ci|commit]] [[-m|--message]] [commit_log_message] [[PATH]]

$ svn log [[-vl|--verbose --limit]] [10]

$ svn [[h|help]]

svn subcommand [options] [args...]
svn help [subcommand]

checkout (co)
    Checks out a working copy from a repository.

update (up)
    Updates a working copy to the latest revision or a specific revision.

commit (ci)
    Sends changes from a working copy to the repository.

add
    Adds files or directories to version control.

delete (del, rm)
    Deletes files or directories from version control.

status (st, stat)
    Prints the status of working copy files and directories.

log
    Shows log messages for revisions.

diff
    Compares changes between revisions or a working copy and a revision.

info
    Displays information about a working copy item or URL.

merge
    Merges changes from one branch to another.

copy (cp)
    Copies files or directories (often used for branching/tagging).

help
    Displays help on a subcommand or general usage.

--username <arg>
    Specifies a username for authentication.

--password <arg>
    Specifies a password for authentication.

The svn command is the primary command-line client for Apache Subversion, a centralized version control system. It allows users to interact with Subversion repositories to manage and track changes to files and directories over time. Key functionalities include checking out code from a repository, updating a working copy with the latest changes, committing local modifications, managing branches and tags, and merging changes between different lines of development. Subversion excels in collaborative environments by providing a robust system for managing revisions, resolving conflicts, and maintaining a complete history of project files. It operates on a client-server model, where a central repository stores all versions of the project data.

Being a centralized version control system, svn relies on a single repository server, which can be a single point of failure. It typically requires an active network connection for most operations like committing or updating, which can be a limitation in offline scenarios. Merging complex histories, particularly across multiple branches, can sometimes be challenging and require careful handling. While robust, its performance on very large repositories or with numerous binary files can sometimes be slower compared to distributed systems.

svn operates by allowing users to create local "working copies" of files and directories from a central "repository". The repository stores the complete history of all project files, while the working copy is where users make their local changes. Operations like checkout create a working copy, update synchronizes it with the repository, and commit sends local changes back to the repository.

Every time changes are committed to a Subversion repository, a new global "revision" number is assigned to the entire repository. This means all changes committed together form a single, atomic transaction; either all changes succeed, or none do. This atomic commit model ensures that the repository's state is always consistent, making it easier to track changes and revert to previous states.

Apache Subversion was initiated in 2000 by CollabNet, aiming to replace CVS (Concurrent Versions System) by addressing its limitations while retaining its centralized model. The first stable version, 1.0, was released in 2004. Subversion gained significant popularity throughout the 2000s, becoming the dominant version control system for many organizations and open-source projects. In 2010, it became a top-level project under the Apache Software Foundation. Although its widespread adoption has been eclipsed by distributed version control systems like Git in recent years, svn continues to be actively maintained and used in many established projects and enterprise environments globally.

cvs(1), git(1), diff(1)