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 mycopyUsing 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 copyHowever, if I cd to the working copy, in this case
www:
% cd www
% svn logthe 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 testThis 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
------------------------------------------------------------------
