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.
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.
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, http://subversion.tigris.org/project_status.html.
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 http://svn.collab.net/repos/svn/trunk/README; 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.
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
First, edit your ~/.subversion/proxies 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.
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.)
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 Poul-Henning Kamp's post to freebsd-hackers: http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING.
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.