From COSSAN Wiki
Jump to: navigation, search

In computing, Subversion (SVN) is a version control system initiated in 2000 by CollabNet Inc. It allows users to keep track of changes made to any type of electronic data, typically source code, web pages or design documents.

Subversion is currently a popular alternative to CVS (another widely used version control system), particularly among open source projects. Projects using Subversion include the Apache Software Foundation, KDE, GNOME, Free Pascal, GCC, Python, Ruby, Sakai, Samba, Mono, and ePresence Interactive Media. and also provide Subversion hosting for their open source projects, Google Code and BountySource systems use it exclusively. Subversion is released under the Apache License, making it free software.

Subversion's Features

  • Most current CVS features.
    • Subversion is meant to be a better CVS, so it has most of CVS's features. Generally, Subversion's interface to a particular feature is similar to CVS's, except where there's a compelling reason to do otherwise.
  • 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.
  • 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.)

  • 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.
  • 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.

How to

How do I check out the Subversion code?

Use the Subversion client:

$ svn co MyOpenCossan

That will check out a copy of the the stable version of OpenCossaan into a directory named MyOpenCossan on your local machine.

How do I create a repository? How do I import data into it?

See [[1]]; specifically, look at section IV, the "Quickstart Guide".

How do I convert an existing CVS repository into a Subversion repository?

Use the tool: cvs2svn. You can find it at Be sure to read the cvs2svn documentation. On Fedora system you can install cvs2svn by means yum:

yum install cvs2svn

How do I manage several different projects under Subversion?

It depends upon the projects involved. If the projects are related, and are likely to share data, then it's best to create one repository with several subdirectories like this:

$ svnadmin create /repo/svn
$ svn mkdir file:///repo/svn/projA
$ svn mkdir file:///repo/svn/projB
$ svn mkdir file:///repo/svn/projC

If the projects are completely unrelated, and not likely to share data between them, then it's probably best to create separate and unrelated repositories.

$ mkdir /repo/svn
$ svnadmin create /repo/svn/projA
$ svnadmin create /repo/svn/projB
$ svnadmin create /repo/svn/projC

The difference between these two approaches is this:

  • In the first case, code can easily be copied or moved around between projects, and the history is preserved. ('svn cp/mv' currently only works within a single repository.)
  • Because revision numbers are repository-wide, a commit to any project in the first case causes a global revision bump. So it might seem a bit odd if somebody has 'projB' checked out, notices that 10 revisions have happened, but projB hasn't changed at all. Not a big deal, really. Just a little weird at first. This used to happen to svn everytime people committed to rapidsvn, when rapidsvn was in the same repository. :-)
  • The second case might be easier to secure; it's easier to insulate projects from each other (in terms of users and permissions) using Apache's access control. In the 1st case, you'll need a fancy hook script in the repository that distinguishes projects ("is this user allowed to commit to this particular subdir?") Of course, we already have such a script, ready for you to use.

Using branches

Create a branch

Creating a branch is very simple—you make a copy of your project tree in the repository using the svn copy command. Since your project's source code is rooted in the /calc/trunk directory, it's that directory that you'll copy. Where should the new copy live? Wherever you wish. The repository location in which branches are stashed is left by Subversion as a matter of project policy. Finally, your branch will need a name to distinguish it from other branches. Once again, the name you choose is unimportant to Subversion—you can use whatever name works best for you and your team.

svn copy \
          -m "Creating a private branch of /calc/trunk."
Bulbgraph.png use a ticket number
A ticket should be create in TRAC explaining the motivation of the brunch. Then use the ticket number as initial name of the branch. E.g. 1089-new-implementation-object

working with a branch

Merging branches

you can can reintegrate you branch with another branch or trunk using the merge command. For instance you might want to merge your branch my-calc-branch to the trunck.



$ svn merge ^/calc/trunk
--- Merging r345 through r356 into '.':
U    button.c
U    integer.c
--- Recording mergeinfo for merge of r345 through r356 into '.':
U   .


the working copy is locked

Your working copy is not corrupt, nor is your data lost. Subversion's working copy is a journaling system, meaning that it logs everything it is about to do before it does so. If the svn client program is interrupted violently (segfault or killed, not with Control-C), then one or more lockfiles are left behind, along with logfiles describing unfinished business. (The `svn status' command will show an 'L' next to locked directories.) Any other process that attempts to access the working copy will fail when it sees the locks. To awaken your working copy, you need to tell the svn client to finish the work. Simply run:

svn cleanup working-copy

the working copy is out of date

Three kinds of situation that can cause this:

  • Debris from a failed commit is littering your working copy.
    • You may have had a commit that went sour between the time the new revision was added in the server and the time your client performed its post-commit admin tasks (including refreshing your local text-base copy). This might happen for various reasons including (rarely) problems in the database back end or (more commonly) network dropouts at exactly the wrong time.
    • If this happens, it's possible that you have already committed the very changes you are trying now to commit. You can use 'svn log -rHEAD' to see if your supposed-failed commit actually succeeded. If it did, run 'svn revert' to revert your local changes, then run 'svn update' to get your own changes back from the server. (Note that only 'svn update' brings your local copies up-to-date; revert doesn't do that.)
  • Mixed revisions.
    • When Subversion commits, the client only bumps the revision numbers of the nodes the commit touches, not all nodes in the working copy. This means that in a single working copy, the files and subdirectories might be at different revisions, depending on when you last committed them. In certain operations (for example, directory property modifications), if the repository has a more recent version of the node, the commit will be rejected, to prevent data loss.
    • You can fix the problem by running the following command in the working copy:
svn update 
  • You might be genuinely out of date — that is, you're trying to commit a change to a file that has been changed by someone else since you last updated your copy of that file.
    • Again, run "svn update" is the way to fix this.

already under version control

The directory you're trying to add already contains a .svn subdirectory, but it's from a different repository than the directory to which you're trying to add it. This probably happened because you used your operating system's "copy" command to copy one working copy into the current one.

The quick and dirty solution is to delete all .svn directories contained in the directory you're trying to add; this will let the "add" command complete. If you're using Unix, this command will delete .svn directories under dir:

 find dir -type d -name .svn -exec rm -rf {} \;

However, you should ask yourself why you made this copy; and you should ensure that by adding this directory, you won't be making an unwanted copy of it in your repository.

Why does subversion need an external editor

If you have the following error when you try to commit:

$ svn commit
svn: Commit failed (details follow):
svn: Could not use external editor to fetch log message; consider setting the $SVN_EDITOR environment
     variable or using the --message (-m) or --file (-F) options
svn: None of the environment variables SVN_EDITOR, VISUAL or EDITOR is set, and no 'editor-cmd'
     run-time configuration option was found

It is customary and good practice to include a comment with each commit. This can be done on the command line with the -m message option or using an editor of your choice. To use and external editor you have to:

  • set the SVN_EDITOR shell variable
 export SVN_EDITOR=xemacs 

It is not advised to set disable comments in the client configuration.

svn commit filename -m "commit comment: blablabla " 

--Ep 16:54, 16 January 2008 (CET)

See also