Setting up Subversion
From Tuxation
Subversion is a free/open-source version control system. That is, Subversion manages files and director- ies over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to your files and directories. This allows you to recover older versions of your data, or examine the history of how your data changed. In this re-gard, many people think of a version control system as a sort of “time machine”.
Subversion can access its repository across networks, which allows it to be used by people on different computers. At some level, the ability for various people to modify and manage the same set of data from their respective locations fosters collaboration. Progress can occur more quickly without a single conduit through which all modifications must occur. And because the work is versioned, you need not fear that quality is the trade-off for losing that conduit—if some incorrect change is made to the data, just undo that change.
Some version control systems are also software configuration management (SCM) systems. These sys- tems are specifically tailored to manage trees of source code, and have many features that are specific to software development—such as natively understanding programming languages, or supplying tools for building software. Subversion, however, is not one of these systems. It is a general system that can be used to manage any collection of files. For you, those files might be source code—for others, anything from grocery shopping lists to digital video mixdowns and beyond.
Contents |
subversion vs. CVS
Directory versioning CVS only tracks the history of individual files, but Subversion implements a “virtual” versioned filesystem that tracks changes to whole directory trees over time. Files and directories are versioned.
True version history Since CVS is limited to file versioning, operations such as copies and renames—which might happen to files, but which are really changes to the contents of some containing directory—aren't supported in CVS. Additionally, in CVS you cannot replace a versioned file with some new thing of the same name without the new item inheriting the history of the old—perhaps completely unrelated—file. With Subversion, you can add, delete, copy, and rename both files and directories. And every newly added file begins with a fresh, clean history all its own.
Atomic commits A collection of modifications either goes into the repository completely, or not at all. This allows developers to construct and commit changes as logical chunks, and prevents problems that can occur when only a portion of a set of changes is successfully sent to the repository.
Versioned metadata Each file and directory has a set of properties—keys and their values—associated with it. You can create and store any arbitrary key/value pairs you wish. Properties are versioned over time, just like file contents.
Choice of network layers Subversion has an abstracted notion of repository access, making it easy for people to implement new network mechanisms. Subversion can plug into the Apache HTTP Server as an extension module. This gives Subversion a big advantage in stability and interoperability, and instant access to existing features provided by that server—authentication, authorization, wire compression, and so on. A more lightweight, standalone Subversion server process is also available. This server speaks a custom protocol which can be easily tunneled over SSH.
Consistent data handling Subversion expresses file differences using a binary differencing algorithm, which works identically on both text (human-readable) and binary (human-unreadable) files. Both types of files are stored equally compressed in the repository, and differences are transmitted in both directions across the network.
Efficient branching and tagging The cost of branching and tagging need not be proportional to the project size. Subversion creates branches and tags by simply copying the project, using a mechanism similar to a hard-link. Thus these operations take only a very small, constant amount of time. Hackability Subversion has no historical baggage; it is implemented as a collection of shared C libraries with well-defined APIs. This makes Subversion extremely maintainable and usable by other applications and languages.
Quick start
Setting up the repository
$ sudo mkdir /home/repo $ sudo svnadmin create /home/repo/ $ ls /home/repo/ README.txt conf dav db format hooks locks
Adding a project
$ sudo svn import /work/ndl/orion/ file:///home/repo/orion -m "initial import"
My directory structure is like this:
/work/{main project name}/{variant project name}/branch
/tag
/trunk/linux-2.6.20
/orion-tc
Checking out the project.
$ sudo svn co file:///home/repo/orion/trunk
Creating a branch
This example creates a new branch called mdl which is a spin-off of orion (which is ndl).
$ sudo svn copy file:///home/repo/orion/trunk file:///home/repo/orion/branch/mdl
To check out the new mdl branch: (Note that I'm setting my workspace to be ~/work/mdl/orion/)
$ cd ~/work $ mkdir mdl $ cd mdl $ svn co file:///home/repo/orion/branch/mdl orion
subversion commands
usage: svn <subcommand> [options] [args] Subversion command-line client, version 1.3.2. Type 'svn help <subcommand>' for help on a specific subcommand. Most subcommands take file and/or directory arguments, recursing on the directories. If no arguments are supplied to such a command, it recurses on the current directory (inclusive) by default. Available subcommands: add blame (praise, annotate, ann) cat checkout (co) cleanup commit (ci) copy (cp) delete (del, remove, rm) diff (di) export help (?, h) import info list (ls) lock log merge mkdir move (mv, rename, ren) propdel (pdel, pd) propedit (pedit, pe) propget (pget, pg) proplist (plist, pl) propset (pset, ps) resolved revert status (stat, st) switch (sw) unlock update (up)
svn checkout
checkout (co): Check out a working copy from a repository.
usage: checkout URL[@REV]... [PATH]
If specified, REV determines in which revision the URL is first
looked up.
If PATH is omitted, the basename of the URL will be used as
the destination. If multiple URLs are given each will be checked
out into a sub-directory of PATH, with the name of the sub-directory
being the basename of the URL.
Valid options:
-r [--revision] arg : ARG (some commands also take ARG1:ARG2 range)
A revision argument can be one of:
NUMBER revision number
"{" DATE "}" revision at start of the date
"HEAD" latest in repository
"BASE" base rev of item's working copy
"COMMITTED" last commit at or before BASE
"PREV" revision just before COMMITTED
-q [--quiet] : print as little as possible
-N [--non-recursive] : operate on single directory only
--username arg : specify a username ARG
--password arg : specify a password ARG
--no-auth-cache : do not cache authentication tokens
--non-interactive : do no interactive prompting
--config-dir arg : read user configuration files from directory ARG
--ignore-externals : ignore externals definitions
svn add
add: Put files and directories under version control, scheduling them for addition to repository. They will be added in next commit. usage: add PATH... Valid options: --targets arg : pass contents of file ARG as additional args -N [--non-recursive] : operate on single directory only -q [--quiet] : print as little as possible --config-dir arg : read user configuration files from directory ARG --force : force operation to run --no-ignore : disregard default and svn:ignore property ignores --auto-props : enable automatic properties --no-auto-props : disable automatic properties
svn commit
commit (ci): Send changes from your working copy to the repository. usage: commit [PATH...] A log message must be provided, but it can be empty. If it is not given by a --message or --file option, an editor will be started. If any targets are (or contain) locked items, those will be unlocked after a successful commit. Valid options: -q [--quiet] : print as little as possible -N [--non-recursive] : operate on single directory only --targets arg : pass contents of file ARG as additional args --no-unlock : don't unlock the targets -m [--message] arg : specify commit message ARG -F [--file] arg : read data from file ARG --force-log : force validity of log message source --editor-cmd arg : use ARG as external editor --encoding arg : treat value as being in charset encoding ARG --username arg : specify a username ARG --password arg : specify a password ARG --no-auth-cache : do not cache authentication tokens --non-interactive : do no interactive prompting --config-dir arg : read user configuration files from directory ARG
