To take over the CVS user base. Specifically, we're writing a new revision 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.
Yes and No.
We say "Yes" because we do believe that Subversion is stable and have confidence in our code, so we've been self-hosting since September of 2001--eating our own caviar so to speak.
We say "No" because if something goes wrong with our svn repository, we've got a horde of active developers who will stay up sleepless nights hunting down the problem and rescuing our data. As altruistic as this horde might be, they don't have time to rescue the data for thousands of people who are storing their data in a pre-alpha product.
We say "No" because there's a good chance that the filesystem might change before we go 1.0, and we don't plan on writing and testing and shipping conversion utilities.
So, as long as you're willing to take those risks, then go right ahead and use Subversion.
Subversion is written in ANSI C and uses the Apache Portable Runtime library as a portability layer. This means that Subversion will compile anywhere Apache httpd does. (Right now, this list includes all flavors of Unix, Win32, BeOS, OS/2, MacOS X.)
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.
If you want to host a networked repository: yes.
If you just want to access a repository with your client: no.
For more details about setting up a network accessible Subversion server, please see Server Setup.
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.
See our status page.
Subversion uses a plugin system to allow access to repositories. Currently there are two of these plugins: ra_local allows access to a local repository, and ra_dav which allows access to a repository via WebDAV 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 the latest README document; specifically, look at section IV, the "Quickstart Guide".
Sometimes you need to run Berkeley DB's recovery procedure. Shut
down apache, cd into the relevant repository's `db'
subdirectory, and run
"/usr/local/BerkeleyDB.X.Y/bin/db_recover -ve".
(Substitute the appropriate major and minor revision numbers of
Berkeley DB for "X" and "Y", of course.)
Of course, we'd prefer that the repository never require human maintenance. However, until we get all the bugs worked out, the above will sometimes be necessary.
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.
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
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.