Our developers are located all around the world. To enable them to work
together on our software, we keep the source code in an Internet-accessible
revision control system called Subversion (SVN). Apache committers
have write access to the Subversion repository, enabling them to make
changes to the source code. Everyone has read access to the repositories, so
you may download the most up-to-date development version of the software.
If you are looking for a stable release of the source code, you
should download it from the distribution directory. The
Subversion repository should only be used if you want to be on the
bleeding-edge of the development effort.
The code contained in them may fail to work, or it may even
eat your hard drive.
There are several ways to access the Subversion repository:
If you just wish to browse around or download a few individual files, the
best tool is the web-based ViewVC interface for
Subversion
or go straight to the public repository at
http://svn.apache.org/repos/asf/.
Many of the projects make snapshots of the source
code available. These are simply tarballs containing the most
up-to-date source code captured four times per day.
To access the Subversion repository anonymously, you will need a
Subversion client. You can also browse for projects via http://svn.apache.org/repos/asf/.
Choose the module you would like and check it out. For example, to
get the Spamassassin module, use:
svn checkout http://svn.apache.org/repos/asf/spamassassin/trunk spamassassin
For more help on using Subversion, consult the Subversion website or
Subversion book.
The web site provides a list of
clients and useful links (including a link to the Eclipse plug-in).
We currently use HTTPS basic authentication for logging in to
Subversion (certificate info below). To change
your password, visit
https://svn.apache.org/change-password.
This will prompt you to enter a svn password of your choice. Pick a safe password! If you cannot login, or have lost your password, send an
email to root@ to request a temporary subversion password.
Now, when you make changes, you can commit them with your
username/password combination, i.e.
svn co https://svn.apache.org/repos/asf/excalibur/trunk/ excalibur-trunk
cd excalibur-trunk
echo "test" > test.txt
svn add test.txt
svn commit --username your-name --password your-password \
--message "Trying out svn"
svnserve is not supported, nor is svn+ssh.
Committers will need to properly configure their svn client.
One particular issue is OS-specific line-endings for text files.
When you add a new text file, especially when applying patches
from Bugzilla, first ensure that the line-endings are appropriate
for your system, then do ...
svn add test.txt
svn propset svn:eol-style native test.txt
Your svn client can be configured to do that automatically
for some common file types. Add the contents of the file http://www.apache.org/dev/svn-eol-style.txt to your
~/.subversion/config file.
[Note: for Windows this is normally found at C:\Documents and Settings\{username}\Application Data\Subversion\config]
Some files may need additional properties to be set, for example svn:executable=* should be applied to
those script files (e.g. .bat, .cgi, .cmd, .sh) that are intended to be executed.
Since not all such files are necessarily intended to be executed,
the executable property should not be made an automatic default.
However, you should still pay attention to the messages from your
svn client when you do 'svn commit'.
The server certificate for https://svn.apache.org/ is a
real SSL certificate. However, Subversion, by default, does not currently
ship with a list of trusted CAs. So, here's some information to help you
verify the validity of our cert:
Hostname: svn.apache.org
Issuer: http://www.starfieldtech.com/repository,
Starfield Technologies, Inc., Scottsdale, Arizona, US
Fingerprint: A7:A5:3F:1A:AE:BB:98:B2:F3:EC:91:1B:63:29:2D:E8:58:B6:53:28
If you're getting an error message like the following:
svn: PROPFIND of '/repos/asf/foobar':
Compressed stream invalid (https://svn.apache.org)
That's a known issue in the neon client library which has been fixed in neon
0.24.7. A workaround is to disable compression in your client. Edit
~/.subversion/servers. Uncomment the [global] section if neccessary, and add a
line that reads
http-compression = no
And that should "fix" the problem until you can upgrade.
If you are using a date revision such as
-r{2004-09-12}:{2004-08-12} and not getting any or all of the
revisions you expected, this is a known problem specific to the ASF
repository.
Unfortunately, there is nothing that can be done to improve this situation,
so you must use a workaround. You can use svn log or ViewVC to
locate the actual revision number that is first after the date you desire, and
substitute that into your -r argument to the svn
command.
For example, consider the desired command:
svn diff -rHEAD:{2005-01-01}
When this produces no output, running svn log alone shows:
...
------------------------------------------------------------------------
r124032 | aheritier | 2005-01-04 09:58:16 +1100 (Tue, 04 Jan 2005) | 1 line
Switch to subversion
------------------------------------------------------------------------
r123911 | brett | 2005-01-03 09:48:57 +1100 (Mon, 03 Jan 2005) | 1 line
remove nagoya references
------------------------------------------------------------------------
r116173 | brett | 2004-10-23 22:11:51 +1000 (Sat, 23 Oct 2004) | 2 lines
remove old requires descriptions
...
So, the comand above should become:
svn diff -rHEAD:123911
The particular reason this occurs is because the order of the revisions
is not identical to the order of dates in the repository. This is a side effect
of loading CVS repositories with history with dates prior to the latest date
in the Subversion repository.
Very rarely - please read this. Commits in subversion
are transactional. This means that locks are almost always unnecessary.
An oft quoted use case is to prevent concurrent editing of a large unmergeable
binary document.
However, for open development, good communication is preferable to locking
even in this use case. A good timely post to the list letting your fellow
developers know that you're going to start editing that huge PDF is better
than locking the file.
Hourly is fine. Please do not use programs that poll the repository more
frequently than hourly. People who run automated scripts that continuously
poll the repository wind up getting their access denied, which may impact
other folks connecting through the same host. If you need to stay more in-sync
than an hourly cron allows, subscribe your script to the relevant commit
mailing list.