AddThis Social Bookmark Button

Print

Accessing Secure Subversion Servers
Pages: 1, 2, 3

Checking Out the Repository

Now that the server is running and authentication works, it's time to access the repository. Because devel1 prefers to work at the command line, I'll demonstrate the svn commands he'll use most often. I'll then install a GUI for devel2 and demonstrate that it is merely a front end for the same commands.



Before you can make any changes to the repository, you must download a working copy to your system. In Subversion terms, this is a checkout. If you always work from the same PC, you need to run this command only once. The syntax is:

% svn checkout svn+ssh://10.1.1.1/usr/home/svn/repository/www
A www/apache
A www/apache/index.html
<snip long output>
Checked out revision 1.

The above command copied the entire repository to a directory called www in devel1's home directory. This is his working copy. If you wish to specify an alternate location for your working copy, place it at the end of the command. For example, this will create a working copy called mycopy:

% svn checkout svn+ssh://10.1.1.1/usr/home/svn/repository/www mycopy

Using your working copy

Once you've checked out your working copy, you can modify its files, add files, and remove files. In order to use any svn commands, your present working directory will have to be somewhere within your working copy. For example, if I try to view the log from devel1's home directory, I'll receive this error:

% pwd
/usr/home/devel1
% svn log
svn: '.' is not a working copy

However, if I cd to the working copy, in this case www:

% cd www
% svn log

the svn command will work. If you get a "working copy" error, cd to your working copy and try again.

It is very important that you always run this command before making any changes to your working copy:

% svn update
At revision 1.

The update command checks your working copy against the repository to ensure that they are the same. Because I just checked out my working copy, there aren't any differences. However, if someone else had made any changes to the repository, that command would download those changes and merge them into my working copy.

Suppose that you want to add a file to a repository. After you have created the file somewhere in your working copy, use svn add to add it. Here, I wish to add a test file called ~devel1/www/test:

% pwd
/usr/home/devel1/www
% svn add test
A	test

This has added the file, but it didn't upload it to the main repository yet. That won't happen until I commit the change:

% svn commit -m "test file added by devel1"
Adding	test
Transmitting file data .
Committed revision 2.

Note that I used the -m switch to add a message to the log and that the revision number has incremented.

You don't have to commit after every change, as svn will queue up your changes and commit everything when you issue svn commit. However, if you're the forgetful sort or if many people work on the repository simultaneously, it doesn't do any harm to commit often. If you do queue up a lot of changes, don't forget to mention them all when you add your message to the log.

Note that the main repository is now at revision 2, but my working copy is still at revision 1. For example, if I type svn log, I won't see my comment. However, if I update, I will:

% svn update
At revision 2.

% svn log
------------------------------------------------------------------
r2 | devel1 | 2005-05-02 11:37:02 -0400 (Mon, 02 May 2005) | 1 line
test file added by devel1
------------------------------------------------------------------
r1 | svn | 2005-04-29 08:31:47 -0400 (Fri, 29 Apr 2005) | 1 line
initial import
------------------------------------------------------------------

Pages: 1, 2, 3

Next Pagearrow