So you want to build a software team? Part 2: Code Sharing

In the last article, we set up development areas for our developers. Now we need to put some code in there and set up a system to share that code between our users.

Let's presume we've got a project structure that looks like this:


What this actually means doesn't really matter for now, but it's useful to have a reference to what we're working with.

Let's also assume that we've got this code structure built in one developer's working area, as ~bob/projects/uberproject. We want any developer to be able to take an up-to-date copy of this code, work with it, and share their changes. To avoid accidentally missing changes, deleting other people's work and thereby throwing team morale through the floor, we'll use version control software; in this case, subversion.

First, we need to install the subversion client and server on our dev box, if it's not already there. In ubuntu, that means (as root) typing apt-get install subversion subversion-tools.

Now we need to create a repository which will act as the central storage location for all of our code. On a shared server, my preference is to put these in /opt/subversion/projectName. So, still working as root:

root@devbox# mkdir -p /opt/subversion/uberproject/repository
root@devbox# svnadmin create /opt/subversion/uberproject/repository

That's it - you've got a repository. Easy, wasn't it?

We need to make sure our developers can all write to this:

root@devbox# addgroup svnusers
root@devbox# chgrp -R svnusers /opt/subversion/uberproject/repository
root@devbox# chmod -R g+wx /opt/subversion/uberproject/repository
root@devbox# adduser bob svnusers

OK, now we actually need to put the code in it. Bob's working area contains the latest version, so let's use that as our source. We'll work as bob now, not root. He may need to log back in now he's got his new group privs.

bob@devbox:~$ cd ~/projects/uberproject
bob@devbox:~/projects/uberproject$ svn import . file:///opt/subversion/uberproject/repository -m \
'Initial Import'
Adding frontend
Adding tests
Adding application
Adding config
Adding libraries

Committed revision 1.

OK, what happened there? Well, we told subversion to import all the code in '.' (the current directory) to our repository, which we identified via the URI of file:///opt/subversion/uberproject/repository. It took everything in that directory (which isn't much yet) and stuck it in the repository.

You're probably wondering about that file:// URI. Why couldn't we just put the repository path? And if we can have file://, what else can we have?

The first answer is just "That's how it works". SVN commands take URIs as their repository arguments, if they need them.

The second answer is: You have a choice of file://, svnserve://, and http:// (or https). We're using file:// for now purely for illustrative purposes, as it's the easiest to set up. It has limitations though, so we'll do something smarter later.

For now, however, we've got code in our repository, but none of our sandboxes (including the area we just checked the code in from) is under version control. We need to replace that sandbox with an svn-controlled version, and check code out from the repository to any other sandbox.

First, move the original work area out of the way:

bob@devbox: ~/projects$ mv uberproject uberproject-pre-svn

and now check out the repository code:

bob@devbox:~/projects$ svn co file:///opt/subversion/uberproject/repository/ uberproject
A frontend
A tests
A application
A config
A libraries
Checked out revision 1.

ie, svn checkout code-at-this-repository-uri to this-target-directory. The precise syntax of that command frequently fools me, and I check out the code a level too high or low. The thing to remember is that, when an SVN repository path ends with a slash, it means "contents of this directory", without the slash it's the directory itself.

If the required target directory already exists, you can check out the code inside it as follows:

bob@devbox:~/projects/uberproject$ svn co file:///opt/subversion/uberproject/repository/ .

Repeat as required for any other developers' sandboxes, and set up web servers as in the last article.

In the next article, we'll learn a little more about subversion, including how to set up remote access to the repository.

Posted by parsingphase, 2008-07-06 12:30

Anonymous user



Contact Richard