Subversion Setup

Accessing the linux-live developers svn subversion is as simple as ABC:

That's it:

When first commit, use the '—username' to specify your sf.net user name.

After the first commit, you don't need to specify '—username' any more. Also, you can use the short from '-m' for '—message'.

documented on: 2007-10-02

How to host several projects (related or unrelated) in a single sf.net svn repository?

Note that the project MetaBuild will be under the 'meta' directory in the sf.net "linux-live developers" repository. The 'svn import' will create those directories, you don't need to create them beforehand.

To check, browse to http://live-developers.svn.sourceforge.net/viewvc/live-developers/

It's OK to remove it now:

documented on: 2007-09-22

Here is what I've tried locally before messing with the sf.net repository:

Subversion typically calls the repository repos. However I'm used to having a cvsroot around so I choose svnroot accordingly.

Once created, the directory structure will look like this:

Now import the above prepared layout tree into the subversion repository:

Note that this will import all the content of tmpsvn, and not the top directory itself.

Now it's time to perform a real checkout.

We can see that it is safe to trash the tmpsvn now.

— empty output now, meaning nothing changed

— svn reports that the file 'trunk/testf' has changed

— Strange! How would I know what's the last commit's changes?

documented on: 2007-10-23

http://wiki.archlinux.org/index.php/Subversion_Setup

http://wiki.archlinux.org/index.php/Subversion_Setup#Create_a_Project

Create the following directory structure on your development machine.

branches tags trunk

You can create them like this.

Put your source files into the created trunk directory.

If everything worked out, you should now have a working, checked out copy of your freshly created SVN repo.

Enjoy!

This page was last modified 03:25, 24 January 2007.

documented on: 2007-09-21

http://ralf.alfray.com/.izumi/LinuxTips.blog?s=20060904_svn_for_the_cvs_dummies

This is a very highly summarized overview of how to use Subversion for those of us who are used to CVS. Note that none of this is original, it is all extracted from the Subversion Book, available freely online.

So first let's install subversion, that's the easy part:

That's the only thing needed as root, unless you want the to use webdav or https over Apache, which I don't care for right now. For using subversion over my lan, I used svnserve.

Now, under whatever user is going to use the repository, we need to create the initial repository itself:

Subversion typically calls the repository repos. However I'm used to having a cvsroot around so I choose svnroot accordingly.

To serve this over the lan, we'll use svnserver. There are lots of possible configuration, including inetd and ssh-tunnel based. The basic command-line manual daemon will work just fine, see the link above for other methods:

Now that's all we need for administration, we can start fiddling with projects.

First, we need to understand what Subversion is and is not:

The only things in common between Subversion and CVS are that both do version control and they have similar patterns for basic operations, meaning the words import, add, update and commit are used to mean the same concepts (contrast this with Perforce where one performs syncs and submits.) The words branches and tags however do not mean the same thing. Nor is the repository concept the same.

So let's be blunt: if you want something that is exactly like CVS, then just stay with CVS. However a quick overview of Subversion instantly shows that it's worth spending the time to adjust to some of its own paradigms:

If you want to understand what this really means, I urge you to read the basic concepts and the branching and merging chapters of the book.

In contrast to CVS, the repository is a unique directory that contains all projects merged together. This is not like CVS where each project is its own little repository. The layout of projects inside the subversion repository is left to the user. There is a canonical layout advocated by the book and it can help to mimic those (so that others accessing your repository can recognize the layout immediately.)

The layout goes like this:

That is the top-level directories of the repository are the projects, which each contain trunk (main development line), branches (full copies of the trunk for branching) and tags (full copies of the trunk for tagging.) It is important to note that the names used (trunk, branches and tags) are pure convention, the names themselves are not special to subversion — we could use "premium, cheese and pythons" except for the fact the users would be totally lost.

Note than one key difference with CVS here is that all projects are just directories in the same repository and remember that revisions are just snapshots (aka sequence numbers of these snapshots) on the ''full' repository. So committing one file in one project essentially snapshots all projects at once. Although it may sound odd at first, one benefit of this is obvious: if one project is a main software and another one is a a common library used by many other projects, you get automatic synchronization between the main software and all its libraries. This makes it easier to create tags and branches that are consistent, where in CVS you'd have to manually tag or branch each individual project.

Another important difference with CVS is how to deal with branches and tags. Contrary to CVS, subversion doesn't have branches or tags per see at all. All it has is the concept of a repository snapshot at time T and a concept of a shadow copy (a.k.a. copy-on-write) which they call cheap copies in Subversion linguo. So really branches and tags are "full" copies of the repository within itself. So the idea is to have the following convention:

Remember that the "branches" and "tags" directories are pure conventions. So in fact you don't even need to bother creating them until you actually need them. And if you plan to never use branches or tags, there's not even the need to have a "trunk" directory in the first place.

So here's an alternate layout that might work better for me:

The thing is that I generally don't need branches. However I use tags to mark releases and I have stable releases vs unstable releases.

So let's try this for my repository:

Note that this will import all the content of tmpsvn, and not the top directory itself.

Now we can trash the tmpsvn and perform a real checkout. The thing is that whatever is checkout will be made a directory, just like a CVS project. So the following svn checkout will only yield workarea/cs/:

However there's a problem here: the top-level of the checkout doesn't seem to have a .svn associated with it, so I can't act on it.

Seems like what I want is really to get svnroot:

Note the URL-like argument above. If we want to use a LAN based svnserve server, we would probably do something like this:

This gets tedious very fast. Of course once you have a working copy you no longer need the URL thing (i.e. just svn status, svn commit, etc.) But still, I miss my old $CVSROOT:

Now back to my repository, I just realized I wanted the following layout:

So in practice I'll have this:

Language name is going to be a full word (shell, python, ruby, csharp, php.) Oops above I started with "cs" instead of csharp. No biggie:

And let's create a bunch of language directories since I'll need them:

However, once I get a bunch of other languages in my repository, I want to be able to only extract a part of it:

-> creates a csharp directory here

-> workarea/csharp/svn

The good part here is that contrary to CVS I can screw up my layout and directory naming scheme and easily fix it. That means I can safely adopt my own repository layout and go back to the traditional trunk/branches/tags later if necessary. The other good part, as seen above, is that you can checkout just a part of an existing bigger repository and not pull everything at once — which incidentally can be used to mimic CVS's per-project repository paradigm.

documented on: 2007-09-22

http://www.linux.org/lessons/advanced/x991.html

Users of Debian and Debian-based distributions (like Ubuntu) just need to issue the following command:

Subversion packages are also included in Red Hat's Fedora Core distribution. If you have the 'yum' package management system installed, you can install subversion by issuing the command:

There, of course, also exists the possibility of installing from source.

First, I created a directory called 'dev' in /home/mike where I am going to keep the repositories for projects I work on. Essentially, what happens is that you have a directory where you're working and a directory where the repository stores that work for version control purposes. These are, of course, separate.

Let's say you've been offered a project to design a website for a restaurant called Larry's Clam Shack. If you want to use subversion for version control on the project, you need to first create a repository. To do this, issue the following command:

Once created, the directory structure will look like this:

According to the developers of, it's a good idea to set up your directory structure for optimum use of subversion. First, create a temporary directory (call it 'tmp' if you want) Then create this directory structure inside of 'tmp':

Now what we'll do is import this layout tree into the subversion repository 'dev':

You'll see a message like this:

You can verify that it got created by issuing the command:

Feel free to remove 'tmp'. I did, anyway, because I get confused easily. I'm actually going to do my work in a directory which will get me the prize for originality: 'work' Now that you're ready to start using the repository. You need to go to the directory that corresponds to 'work' and "checkout" the repository. Once you're in your work directory, issue the following command:

You should see the following:

Now that you've got your work area set up, you are free to add files. If you look inside the directory that the checkout created, you'll find the layout we set up for subversion:

It's in the 'trunk' directory where we'll be storing out files. For example, I first created a directory to save the documentation for the project then I added it to the repository:

Then we would commit it to the repository. Doing a 'commit' is like saying: "Yes, I really want this in there".

In the docs/ directory, I created a file called 'notes' where I will jot down things that I have to remember about the project. After creating the first entry, I added it as well:

And then I committed it:

I assume you're getting the idea here.

As you're working on your project, and you want to see what changes you've been making, you can issue the following command to see that:

If you're hard at work on your work copy and you want to look at the differences between what you've got and what you started with, you can issue a diff command:

If you find that you're changes aren't what you really wanted, you can convert (or revert) back to the repository's copy with:

Since subversion was meant to be a substitute for CVS, its advantages are essentially fixes of what was lacking in CVS. For example, aborted commit actions in CVS sometimes result in the corruption of the repository. This doesn't happen with subversion. There is also better support for retaining version and history information of files when they are moved or renamed. It has also better built-in binary file support than CVS.

At any rate, whether you use CVS or subversion, there's no debate about the importance of some version control system for a programmer.

Copyright Linux Online Inc. Compilation (c) 1994-2007 Linux Online, Inc.

documented on: 2007-09-22

http://www.linuxformat.co.uk/wiki/index.php/Subversion_-_Setting_up

(Original version written by Graham Morrison for Linux Format magazine issue 68.)

Computers are networked together and development projects of hundreds or even thousands of people are actively sustaining themselves. Without online collaboration there would be no Linux.

The magic behind collaborative project development is called version control, and as the name suggests, it's software designed to keep track of every single change or revision. This is more complicated than it sounds. What do you do if there's more than one developer working on the same piece of code? Or if an addition breaks the project in some way? RCS, the original Revision Control System was designed to address many of these problems, and in its turn the Concurrent Versions System (CVS) was designed to plug some RCS holes. Specifically, CVS was intended to handle a whole project rather than separate files.

CVS uses a simple concept. A project's source-tree is stored on the server, known as the repository. Each developer then needs to checkout their own copies of this tree by downloading the source to their local machine, which becomes their working copy. Any changes a developer makes to their working copy need to be committed back to the repository. If more than one developer has altered a piece of code, creating a conflict that CVS cannot resolve, the code needs to be manually edited before the server will allow the commit.

68_tut_svn_02.png-thumb.png (http://www.linuxformat.co.uk/images/wiki/68_tut_svn_02.png)

CVS and SVN share the same development cycle.

As you might expect, CVS is built using a client/server model. The server handles the content while the client requests changes to be made to the server's document tree.

CVS is basically a multi-document extension to RCS, and has inherited many of the problems associated with its progenitor, and even managed to add a few of its own. This is where Subversion comes in. Subversion was developed as a direct replacement for CVS, built from the ground up to solve many of CVS's problems. Top of its features list is version control for directories; not just files as with CVS. This makes a massive difference, as Subversion lets you manipulate directories in the same way you can files, moving, renaming, copying and deleting. The other big problem with CVS is also a direct result of its file based structure. It's possible to get half way through a commit and lose the connection. The result is that half the files from a developer may be updated, while the other half aren't, leaving the administrator with no way of knowing which files were updated and which weren't.

The solution, as provided by Subversion, is to make all changes to the repository 'atomic'. This means that all changes are updated as a single transaction, avoiding half updated errors and dual commits. This, along with other essential additions (resource cheap branching and tagging, excellent support for binary formats) makes upgrading to Subversion almost imperative for CVS users at some point in the not-too-distant future.

Once installed, the first step to administering a subversion repository is obviously to create the structure and populate it with files. Subversion uses the Berkeley database which restricts installation to a local file system. This is because Berkeley relies on a file system that supports relatively advanced features not currently available over a network equivalent (such as Samba or NFS). Once a suitable location for the repository has been selected, a repository can be created using a command Subversion reserved for dramatic repository changes, called svnadmin.

To create your own repository called subres, execute the following from the directory you wish the repository to reside (I've used /usr/share):

Managing a Subversion repository isn't all that different from managing a CVS one but as an administrator, the most important thing to understand is the Subversion file system. This isn't a file system in the same way you think of ext3 or Reiser, but instead, it's the file structure and organisation that SVN expects. The previous command generated this structure under the subres directory, which should now contain a couple of files and several directories.

There are five directories in total; conf, dav, db, hooks and locks. Conf contains a repository's specific configuration file called svnserver.conf. The dav directory contains the system's bookkeeping information, specifically used with the Apache access modules. The aforementioned Berkeley database system uses the db directory for all its files.

Hooks are scripts that can be triggered by a specific repository event. These events include commits, or version changes, and the hook directory contains an example script for each action that SVN implements. The locks directory is used for containing the locking data, responsible for tracking accesses to the repository.