General questions:
How-to:
Troubleshooting:
References:
To take over the CVS user base. Specifically, we're writing a new version control system that is very similar to CVS, but fixes many things that are broken. See our front page.
No, Subversion is open source / free software. CollabNet pays the salaries of several full-time developers, and holds the copyright on the code, but that copyright is an Apache/BSD-style license which is fully compliant with the Debian Free Software Guidelines. In other words, you are free to download, modify, and redistribute Subversion as you please; no permission from CollabNet or anyone else is required.
We think so!
Because:All modern flavors of Unix, Win32, BeOS, OS/2, MacOS X.
See http://svn.collab.net/repos/svn/trunk/PORTING for details about individual platforms.
Subversion is written in ANSI C and uses APR, the Apache Portable Runtime library, as a portability layer. Although the Subversion client will compile anywhere APR does, the Subversion server depends on Berkeley DB (as well as Apache 2.X, but Apache is as portable as APR). In theory Berkeley DB is portable to most of those platforms as well (except Win95/Win98, where it's known not to work due to shared-memory segment problems). In practice, it's difficult to get the Subversion repository running on non-Unix platforms; if you succeed, we'd like to hear about it.
No. The "Subversion Filesystem" is not a kernel-level filesystem that one would install in an operating system. Instead, it refers to the design of Subversion's repository. The repository is built on a database (currently Berkeley DB) and exports a C API that simulates a filesystem -- a versioned filesystem. Thus writing a program to access the repository is like writing against other filesystem APIs. The main difference is that this particular filesystem doesn't lose data when written to; old versions of files and directories are saved.
No. Subversion is a set of libraries. It comes with a command-line client that uses them. The Subversion server is Apache + mod_dav + mod_dav_svn, and the last module uses the Subversion libraries to speak to a repository. For more information about how Subversion uses WebDAV as its network protocol, see our docs. Also, as an alternative to Apache, you can use a small standalone Subversion server process. This will allow you to tunnel a custom protocol over ssh.
The short answer: no.
The long answer: if you just want to access a repository, then you only need to build a Subversion client. If you want to host a networked repository, then you either need to set up Apache2 or use our standalone server process over ssh.
For more details about setting up a network accessible Subversion server, please read our INSTALL document.
Don't worry, you can run Apache 2.0 on a different port, while continuing to run Apache 1.x on port 80. Different versions of Apache can happily coexist on the same machine. Just change the Listen directive in httpd.conf from "Listen 80" to "Listen 8080" or whatever port number you want, and make sure to specify that port when you publish your repository URL (e.g., http://svn.mydomain.com:8080/repos/blah/trunk/).
We aren't attempting to break new ground in SCM systems, nor are we attempting to imitate all the best features of every SCM system out there. We're trying to replace CVS. See the first question.
The global revision number attached to the repository as a whole is meaningless from a user's perspective. It's an internal mechanism that accomplishes the goal of the underlying schema design. It just so happens to be exposed so that the user's interface can sometimes be a little more convenient than always having to type obnoxiously long date/time strings.
The revision number is only relevant to the repository, and user convenience. It has no impact on any other factor of what you store in the repository. Repository revision number bumps aren't nearly useful enough to be an accurate indication of the real rate of change of a given code base. There are other more complicated ways to get a much better picture of a code-base's rate of change.
See our status page, http://subversion.tigris.org/project_status.html.
Please send your questions or concerns to the Subversion Development mailing list. Alternatively, several Subversion users and developers can usually be contacted via IRC on channel #svn on irc.openprojects.net.
Use the subversion client:
$ svn co http://svn.collab.net/repos/svn/trunk subversion
That will check out a copy of the Subversion source tree into a directory named subversion on your local machine.
See http://svn.collab.net/repos/svn/trunk/README; specifically, look at section IV, the "Quickstart Guide".
cvs2svn.py will be completed and well tested for Subversion's 1.0 release, but for now, use it with caution.
The Subversion client can go through a proxy, if you configure it to do so. First, edit your ~/.subversion/servers configuration file to indicate which proxy to use. There are comments in the file explaining how to do this. If you don't have that file, get the latest Subversion client and run any command; this will cause the configuration directory and template files to be created.
Older versions of Subversion, including the 0.14.3 bootstrap tarball, use the file ~/.subversion/proxies to define the proxy settings. This file is ignored by the current version of Subversion.
Next, you need to make sure the proxy server itself supports all the HTTP methods Subversion uses. Some proxy servers do not support these methods by default: PROPFIND, REPORT, MERGE, MKACTIVITY, CHECKOUT. In general, solving this depends on the particular proxy software. For Squid, the config option is
# TAG: extension_methods # Squid only knows about standardized HTTP request methods. # You can add up to 20 additional "extension" methods here. # #Default: # none extension_methods REPORT MERGE MKACTIVITY CHECKOUT
(Squid 2.4 and later already knows about PROPFIND.)
See also "What are all the HTTP methods Subversion uses?" for advice on additional HTTP methods to allow through your proxy.
If it's difficult or impossible to get the proxy to allow Subversion traffic, but you want to check out the Subversion sources, you may be able to go around the proxy. Some proxies that filter port 80 nevertheless allow anything on port 81. For this reason, the svn.collab.net repository server listens on port 81 as well as on port 80. Try:
svn checkout http://svn.collab.net:81/repos/svn/trunk subversion
and maybe the proxy will let you through. Another strategy is to attempt the checkout over SSL, which many proxies allow:
svn checkout https://svn.collab.net/repos/svn/trunk subversion
Of course, your svn client will have to have been built with ssl support; just pass --with-ssl to subversion's ./configure script. You can check to see whether the 'https' schema is supported by running svn --version.
If you previously used CVS, you may have used SSH to login to the CVS server. The preferred solution would be to use ra_dav combined with an Apache HTTP server configured with mod_ssl and appropriate authentication support. This should provide enough security for most users. However, we realize that there are places that do not allow adding servers of any kind with external connectivity.
There has been work on a ra_pipe implementation that would work similarly to the CVS_RSH mechanism, but it is not currently complete. If you wish to contribute to its development, you are more than welcome to do so!
However, another solution that can be used instead is to leverage SSH port forwarding to connect to the protected server via ra_dav. You would connect via SSH to a machine behind your firewall that can access your Subversion server. Note that this SSH server does not have to be the same as where Subversion is installed. It can be, but it doesn't have to be.
Then, you create a local port forward that connects to the HTTP server that houses your Subversion repository. You would then 'connect' to the Subversion repository via this local port. Then, the request will be sent 'tunneled' via SSH server to your Subversion server.
An example: a Subversion ra_dav setup is behind your company firewall at 10.1.1.50 (call it svn-server.example.com). Your company allows SSH access via publicly accessible ssh-server.example.com. Internally, you can access the Subversion repository via http://svn-server.example.com/repos/ours.
Example: client connecting to ssh-server with port-forwarding and checking out via the port forward
% ssh -L 8888:svn-server.example.com:80 me@ssh-server.example.com % svn checkout http://localhost:8888/repos/ours
Note that your svn-server.example.com could also have its httpd instance running on an unpriviliged port by a non-trusted user. This will allow your Subversion server not to require root access.
Joe Orton notes
The server is sensitive to the hostname used in the Destination header in MOVE and COPY requests, so you have to be a little careful here - a "ServerAlias localhost" may be required to get this working properly.
Some links on SSH port forwarding
It depends upon the projects involved. If the projects are related, and are likely to share data, then it's best to create one repository with several subdirectories like this:
$ svnadmin create /repo/svn $ svn mkdir file:///repo/svn/projA $ svn mkdir file:///repo/svn/projB $ svn mkdir file:///repo/svn/projCIf the projects are completely unrelated, and not likely to share data between them, then it's probably best to create separate and unrelated repositories.
$ mkdir /repo/svn $ svnadmin create /repo/svn/projA $ svnadmin create /repo/svn/projB $ svnadmin create /repo/svn/projC
The difference between these two approaches is this (as explained by Ben Collins-Sussman <sussman@collab.net>):
In the first case, code can easily be copied or moved around
between projects, and the history is preserved. ('svn cp/mv'
currently only works within a single repository.)
Because revision numbers are repository-wide, a commit to any
project in the first case causes a global revision bump. So it
might seem a bit odd if somebody has 'projB' checked out, notices
that 10 revisions have happened, but projB hasn't changed at
all. Not a big deal, really. Just a little weird at first.
This already happens to svn, everytime people commit to
rapidsvn. :-)
The second case might be easier to secure; it's easier to insulate
projects from each other (in terms of users and permissions)
using Apache's access control. In the 1st case, you'll need a
fancy hook script in the repository that distinguishes projects
("is this user allowed to commit to this particular subdir?") Of
course, we already have such a script, ready for you to use.
If you don't care about retaining all the history of one of the repositories, you can just create a new directory under one project's repository, then import the other.
If you care about retaining the history of both, then you can use 'svnadmin dump' to dump one repository, and 'svnadmin load' to load it into the other repository. The revision numbers will be off, but you'll still have the history.
Peter Davis <peter@pdavis.cx> also explains a method using svn's equivalent to CVS modules:
As long as the merging takes place in separate directory trees, you can use svn's version of CVS modules.
Set the svn:externals property on a directory to checkout directories from other repositories whenever the original directory is checked out. The repository remains separate, but in the working copy it appears that they have been merged. If you commit to the imported directory, it will affect the external repository.
The merge isn't completely clean: the import only affects working copies, so you won't be able to use a URL in the first repository to access modules imported from the second. They remain separate URLs.
FIRST, read the HACKING document.
Once you've digested that, send a mail to the dev list with the word [PATCH] and a one-line description in the subject, and include the patch inline in your mail (unless your MUA munges it up totally). Then a committer will pick it up, apply it (making any formatting or content changes necessary), and check it in.
The basic process looks like this:
Of course, the email you send should contain a nice long explanation about what the patch does, as per the HACKING document, but you already know that, since you read and completely understood it before actually hacking the code, right? :)$ svn co http://svn.collab.net/repos/svn/trunk subversion $ cd subversion/www [ make changes to project_faq.html ] $ svn diff project_faq.html > /tmp/foo $ Mail -s "[PATCH] FAQ updates" < /tmp/foo
This happens when your diff utilities are not installed on the default location, which on Windows is C:\Cygwin\bin. This is caused by a bug in Subversion's config file processing, which was fixed in revision 4578 (version 0.17.1+).
The workaround is to add a non-standard option to your configuration file. For example, if your diff utilities are installed in D:\Cygwin\bin, your config file probably contains:
[helpers] diff-cmd = D:\Cygwin\bin\diff.exe diff3-cmd = D:\Cygwin\bin\diff3.exe
Adding the following line to the [helpers] section should fix this problem:
diff_cmd = D:\Cygwin\bin\diff.exe
Your repository is not corrupt, nor is your data lost. If your process accesses the repository directly (mod_dav_svn, svnlook, svnadmin, or if you access a `file://' URL), then it's using Berkeley DB to access your data. Berkeley DB is journaling system, meaning that it logs everything it is about to do before it does so. If your process is interrupted (Control-C, or segfault), then a lockfile is left behind, along with a logfile describing unfinished business. Any other process that attempts to access the database will just hang, waiting for the lockfile to disappear. To awaken your repository, you need to ask Berkeley DB to either finish the work, or rewind the database to a previous state that is known to be consistent. Simply run:
svnadmin recover /path/to/repos
Make sure you disable all access to the repository before doing this (by shutting down Apache). Make sure you run this command as the user that owns and manages the database, and not as root, else it will leave root-owned files in the db directory which cannot be opened by the non-root user that manages the database, which is typically either you or your Apache process.
Your working copy is not corrupt, nor is your data lost. Subversion's working copy is journaling system, meaning that it logs everything it is about to do before it does so. If the svn client program is interrupted (Control-C, or segfault), then one or more lockfiles are left behind, along with logfiles describing unfinished business. (The`svn status' command will show an 'L' next to locked directories.) Any other process that attempts to access the working copy will fail when it sees the locks. To awaken your working copy, you need to tell the svn client to finish the work. Simply run:
svn cleanup working-copy
Subversion uses a plugin system to allow access to repositories. Currently there are three of these plugins: ra_local allows access to a local repository, ra_dav which allows access to a repository via WebDAV, and ra_svn allows local or remote access via the svnserve server. When you attempt to perform an operation in subversion, the program tries to dynamically load a plugin based on the URL scheme. A `file://' URL will try to load ra_local, and an `http://' URL will try to load ra_dav.
The error you are seeing means that the dynamic linker/loader can't find the plugins to load. This normally happens when you build subversion with shared libraries, then attempt to run it without first running 'make install'. Another possible cause is that you ran make install, but the libraries were installed in a location that the dynamic linker/loader doesn't recognize. Under Linux, you can allow the linker/loader to find the libraries by adding the library directory to /etc/ld.so.conf and running ldconfig. If you don't wish to do this, or you don't have root access, you can also specify the library directory in the LD_LIBRARY_PATH environment variable.
See this faq.
You probably have old copies of /usr/local/bin/apr-config and /usr/local/bin/apu-config on your system. Remove them, make sure the apr/ and apr-util/ that you're building with are completely up-to-date, and try again.
Probably you just need to get the latest platform SDK. The one that ships with VC++ 6.0 is not recent enough.
If the error looks something like:
svn_error: #21085 :Then the problem is that Subversion doesn't yet handle file URLs that have a drive specification. Try changing to that drive then doing an import without the drive spec. For example:svn_ra_local__split_URL: Unable to find valid repository
d: svn import file:///some/path/to/repos/on/d/drive e:\file\to\be\imported
For example, one user reported that imports worked fine over local access:
$ mkdir test $ touch test/testfile $ svn import file:///var/svn/test test test -m "Initial import" Adding test/testfile Transmitting file data . Committed revision 1.But not from a remote host:
$ svn import http://svn.sabi.net/test testfile -m "import" nicholas's password: xxxxxxx svn_error: #21110 :The specified activity does not exist.
We've seen this when the REPOS/dav/ directory is not writable by the httpd process. Check the permissions to ensure Apache can write to the dav/ directory (and to db/, of course).
You need to install Window XP Service Pack 1. You can get all sorts of information about that Service Pack here:
Use Ethereal to eavesdrop on the conversation:
port 80 for Filter, and turn off
promiscuous mode.Alternatively, if you have an up-to-date client (more recent than the 0.16 tarball) you may set the http-debug parameter in the servers configuration file to cause neon's debugging output to appear when you run the svn client. The numeric value of neon-debug is a combination of the NE_DBG_... values in the header file ne_utils.h. For neon 0.23.7 setting http-debug to 130 (i.e. NE_DBG_HTTP+NE_DBG_HTTPBODY) will cause the HTTP data to be shown.
You may well want to disable compression when doing a network trace, see the compression parameter in the config configuration file.
The following email says it all. As the author points out, Subversion does not actually use all of these WebDAV/DeltaV methods yet, but it probably will someday, so if you're configuring a proxy, you might as well allow all of them:
From: Nuutti Kotivuori <naked@iki.fi> Subject: Re: list of HTTP messages used by svn? To: "Hamilton Link" <helink@sandia.gov> Cc: dev@subversion.tigris.org Date: Sat, 10 Aug 2002 13:51:52 +0300 Hamilton Link wrote: > Is there a full list of the HTTP methods svn uses somewhere, that > someone could piont me to? From the documentation I can find (in > particular project_faq.html and INSTALL), the list of methods svn > uses include at least the following: > > GET, PROPFIND, REPORT, OPTIONS, MERGE, MKACTIVITY, and CHECKOUT > > But since the lists I can find are only partial lists and nowhere > does it suggest these are all the ones used, I'm reluctant to make > any assumptions. > > If I had a complete list, I could go to the corp. proxy guy once > instead of many times, and reduce the risk of pissing him off and > being left with inadequate svn support in the proxy. http://www.webdav.org/deltav/WWW10/deltav-intro.htm A list copied from there: HTTP/1.1: GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE, CONNECT WebDAV: LOCK, UNLOCK, PROPFIND, PROPPATCH, COPY, MOVE, MKCOL DeltaV: CHECKIN, CHECKOUT, UNCHECKOUT, VERSION-CONTROL, REPORT, UPDATE, LABEL, MERGE, MKWORKSPACE, BASELINE-CONTROL, MKACTIVITY Subversion uses no methods outside these. It doesn't use all of them either, but it's better to support the full WebDAV/DeltaV than just some arbitrary subset. If the proxy being configured is a recent Squid, it probably has everything from HTTP/1.1 and WebDAV - and then it only needs the DeltaV extensions added. You can give that list to your corp. proxy guy and explain to him that he can check the RFC's for further information.
See Poul-Henning Kamp's post to freebsd-hackers: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING.