Please, as you hurt others if you use SVN for your open source project, best is to abstain from SVN.

Only if SVN bootstraps cleanly on all systems on which your open source project is supposed to run anyway, then you can use SVN. However if your open source project is thought for people too, which may have problems with getting SVN run on their system, then do never even consider using SVN at all.

Why?

It is to give others an easy way to upgrade to new versions of your software. To compile from a distribution often is very painful, as you loose all your settings, have to run ./configure again etc.

If your re-compile is more complex than "wget; gtar xfz; make; make install", then you should give people a more easy way to upgrade, like "cvs update -d; ./configure; make; make install". As anything else simply is too much effort.

If you release new versions, others might want to update through a VCS, as this is more easy to do than to do a full download again.

Nice people do not expose SVN to the public

SVN only is for the "elite" (in the bad sense). If you try to bootstrap SVN you need SVN. This is a classical no-brainer deadlock:

$ ./configure
configure: Configuring Subversion 1.5.2
configure: creating config.nice
checking for gcc... gcc
checking for C compiler default output file name... a.out checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed checking how to run the C preprocessor... gcc -E
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... i686-pc-linux-gnu
checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E
checking whether ln -s works... yes
checking for a BSD-compatible install... /usr/bin/install -c checking for static Apache module support... no
checking for Apache module support via DSO through APXS... no - Unable to locate /usr/include/apache/mod_dav.h ================================================================== WARNING: skipping the build of mod_dav_svn
--with-apxs or --with-apache must be used

================================================================== configure: Apache Portable Runtime (APR) library configuration checking for APR... no
configure: WARNING: APR not found
The Apache Portable Runtime (APR) library cannot be found. Please install APR on this system and supply the appropriate --with-apr option to 'configure'

or

get it with SVN and put it in a subdirectory of this source:

svn co \
svn.apache.org/repos/asf/apr/apr/branches/0.9.x \
apr
Run that right here in the top level of the Subversion tree. Afterwards, run apr/buildconf in that subdirectory and then run configure again here.

Whichever of the above you do, you probably need to do something similar for apr-util, either providing both --with-apr and --with-apr-util to 'configure', or
getting both from SVN with:

svn co \
svn.apache.org/repos/asf/apr/apr-util/branches/0.9.x \ apr-util
configure: error: no suitable apr found

$ make
make: *** No targets specified and no makefile found. Stop.

More information on VCS bootstrap needs

-Tino, 2008-09-15

SVN short howto

Anyway, as there enough idiots out there who martyr you with SVN, here are the most basic SVN commands. This is for MY convenience, as I do not want to remember such crappy things like SVN:

Initial checkout:
svn co http://servername/path/something/trunk/ name
Often the URL is made up as told above. You can open the URL within your browser. NAME is the subdirectory you want the sources to be checked out to.

Update:
svn up
Enter the directory where you have checked out the data. Then use this command.

More commands are not needed by me, as I never want to use such an SVN more directly.

Final words:

Yes, I use SVN, however only in the form "tortoise-svn". This is a very usable tool under windows.

However I do not use it for any other important purpose, than to keep some versioning easily on an external drive. SVN has some properties which are better than CVS, as it does not alter the old repository files, it only adds new ones. Therefor the former files can be kept and stay readonly.

This is the only thing why I use SVN: Windows and unimportant internal only stuff due to Tortoise-SVN.

My important things I still keep in CVS, as I never found any other VCS which does have the basic features of CVS, is likewise stable (I never lost files due to CVS, however I lost files due to SVN stable release), portable (can be compiled on machines unmodified since 1989, my first Unix box), and just works as a breeze. Note that:
  • I need that the VCS writes IDs about the current version into the source files.
  • it must not harm files in any way, even if I enter some irregular commands (CVS does not fulfill this, however I know how to use CVS blindly, so I never enter something such irregular there. A newer VCS I have to learn first, so I will do mistakes, so it must be secured against any form of mistakes)
  • it must be easy to use. Much more easy than CVS. This means: It must not contain a server part (any non-CGI HTTP server must be the server). It must be able to run locally on distributed machines without need for networking or other type of shared resources.
-Tino, 2008-11-25