Created at:
SVN notes
SVN client howto
Important: When doing operations on the repository with the svn
command, it is
necessary to specify the full repository path. For example, supposing that
the server is serving svn using ssh. To checkout a directory of a project,
do (see the SVN FAQ):
$ svn checkout svn+ssh://hostname/path/to/repository/project/trunk
It will make login like logging in a machine through ssh.
Accessing the repository through ssh
This requires a Unix account on the SVN server.
After setting up a SVN repository, it will be necessary to create individual directories for the projects::
$ svn mkdir svn+ssh://hostname/path/to/repository/project
It is convention for subversion users to create some directories below the project root:
- trunk/
- main flow of development
- branches/
- any branches of development
- tags/
- snapshots of the repository
So:
$ svn mkdir svn+ssh://hostname/path/to/repository/project/trunk
$ svn mkdir svn+ssh://hostname/path/to/repository/project/branches
$ svn mkdir svn+ssh://hostname/path/to/repository/project/tags
After that, just checkout the project:
$ svn checkout svn+ssh://hostname/path/to/repository/project
You can also, easily, checkout the whole repository and run mkdir command on it:
$ svn checkout svn+ssh://hostname/path/to/repository
$ svn mkdir project
$ svn mkdir project/trunk
$ svn mkdir project/branches
$ svn mkdir project/tags
$ svn commit
And it is ready to get work done on the trunk/
directory.
Accessing the repository without ssh
The commands are the same, but instead of specify the svn+ssh://
protocol,
just specify svn://
. Also, if the port is not default, specify it in the
command line, as shown in the example below (which uses the port 21 to run
svnserve):
$ svn checkout svn://hostname:21/path/to/repository/project/tags
Remember that it is not required to have a Unix account on the SVN server, but
you need to have access to the repository by creating a user in the repository
configuration (conf/<configuration files>
). Ask for the SVN administrator to
create a user there for you.
If everything is ok, you will be prompted out for a password. Just insert it and everything is working!
SVN server setup
Creating the repository
In NetBSD, subversion-base package is enough for a basic installation. Once you have it installed, create the repository as the user that will own it:
$ su - svn
$ svnadmin create <your repository path>
Once you have been set up the repository, there are several ways to make it available remotelly. Using WebDAV is the most common way, but classical SSH access looks easier and secure, but according to the svnbook_, it is not useful when used for many developers. I recommend using ssh only if it is a single user.
Using SSH method to access the repository
So, to enable SSH access to the repository, call the svnserve
command:
$ svnserve -t -r <your repository path>
2004 list thread about svnserve
Append the -d
option to make it behave like a daemon, which means that it
backgrounds itself. Useful for starting it at the system boot time.
Using svnserve without ssh
According to link below, it is recommended to use svnserve without ssh when there are many developers wishing to access the same repository. It is simple to set up, effective and not really unsecure (although code surfs raw through the cable, the password never goes raw).
SVN With Multiple Users on the Grid
So, to set it up, following svnbook_, put it in /etc/inetd.conf
or in
/etc/xinetd.d/svnserve
. See this xinetd serve example::
# default: on
# Subversion server
service svn
{
socket_type = stream
protocol = tcp
user = svn
wait = no
disable = no
server = /usr/bin/svnserve
server_args = -i
port = 3690
}
You can also run it like a standalone daemon, with the -d
option.
Authentication and access control
A section of svnbook (linked below) explains very well authentication and access
control. About authentication, if we use svnserve + ssh method, we need to
create a Unix account on the machine, for each user that wants to access the
repository. If we use svnserve without ssh, there are several ways to make
authentication (LDAP and others), but simplest way is to set up the
conf/users.cfg
file in the repository. Access control is made in
conf/authz.cfg
file (those names are flexible and configured in the
conf/svnserve.conf
, in the repository).
svnserve: Built-in authentication and authorization
The conf/svnserve.conf
file is the main configuration file, which points
to the others (conf/users.cfg
or authz.cfg
in the examples given
above).
An example of the conf/svnserve.conf
file is given below:
[general]
# Global access settings.
anon-access = none
auth-access = write
# Users and their passwords
password-db = users.cfg
# Path-specific constraints
authz-db = authz.cfg
realm = My repository name
Importing CVS modules to a SVN repository
If you used to use CVS and is migrating to subversion, you can use cvs2svn program. The cvs2svn FAQ teaches a way of importing one module at a time, instead of convert the whole CVS repository to a SVN repository.
Basically, the process consists in copying the cvs2svn-example.option
file, modify it and run with the following command:
$ cvs2svn --options=<your modified option file>
If your repository already exists (which means that you don't want to create a
new one), specify it in the ExistingRepositoryOutputOption()
function
instead of the NewRepositoryOutputOption()
. (cvs2svn version 2.1.1).
Working with branches and tags
You create a branch with svn copy
::
$ svn copy trunk branches/version-2-0
Subversion use the same command for both branches and tags. Therefore, the
difference between them is just the use you make for it. If you never do any
commit in a directory created by svn copy
, it is then a tag.
To merge_ changes from another branch, use svn merge
. You will always
have to checkout at least the branch you want to merge to:
$ svn checkout svn+ssh://hostname/path/to/repository/project/trunk
$ cd trunk
$ svn merge svn+ssh://hostname/path/to/repository/project/branches/mybranch
There can be things like conflicts on files. They normally appear if different changes were made in the same file for different branches. Resolving conflicts in subversion can be frightening.
svn merge
changes your working tree. If you do not want to do that, but
only want to be sure that the merge succeds without conflicts, use the
--dry-run
option:
$ svn merge --dry-run svn+ssh://hostname/path/to/repository/project/branches/mybranch
To rollback a commit, or a list of commits, you should also use svn
merge
:
$ svn merge -r HEAD:140 .
This command applies a revert diff at the top of your working directory, so it changes everything to make it equal to the 140th revision of your repository.
How do I return to an older version of our code in Subversion?
There are other commands that may come to help when doing merges. The command
svn mergeinfo
show important stuff like the common ancestor for two
branches and when the last merge ocurred:
To view merge information of a branch, use the following command:
$ svn propget -R svn:mergeinfo svn+ssh://hostname/path/to/repository/branch
Check if trunk commit was merged from branch
Mirroring the repository
I sometimes want to make tests on the repository but don't want to mess with the repository history. In this situation, I create a temporary and local mirror and work there.
For this, use svnsync
.
Making a local mirror of a subversion repository: using svnsync
Troubleshooting
Your repo location changed, and your working copy points to the old location
In this case, just use the svn switch
command, with the
--relocate
flag::
svn switch --relocate svn://old/svn/location svn://new/svn/location
Check the svn switch manual for more information.
Cannot delete file or directory with an at sign (
@
) in the name
If you (deliberately or by mistake) has a file with an at sign, you will
realise that you cannot delete it or even make another change using svn
.
This is because @
is used as a special character to separate filenames
from revisions.
If you want to force it to be handled as a normal @
character, just add
another @
at the end (the last one, therefore, will be handled as a
special one).
SVN: Peg and Operative Revisions
svn commands
say: svn: generic failure
Subversion commands can give you the following error::
svn: generic failure
Lots of different reasons can produce this problem. See links below, that say
that this could be a problem with one of subversion dependencies, but in my case the
problem was that my machine hostname was different of the name for the address
127.0.0.1 in /etc/hosts
. I changed /etc/hosts
to match my hostname
and it started to work.
saslpasswd2: generic failure on Windows