QuantLib SVN Repository
Using Subversion
If you're new to Subversion, please read the free SVN book; you might want to start from the guided tour, which contains most of the information you need to get started.
Besides the technicalities of accessing the repository (covered in the SVN book) a few words of advice are needed regarding the policy for committing changes.
The main difference between Subversion and CVS is that in Subversion, commits are a single entity, even when committing files from different directories. Files no longer have revision numbers; instead, the whole repository is versioned and a revision number is assigned to each commit as a whole. In order to take advantage of this scheme, developers should take care of a few things, namely:
- Do not commit changes across files, directories, or even modules, in separate commits; always commit from the root of the module you're working on. Moreover, developers working on several modules are advised to check out the entire trunk (or branch.) When you make related changes in different modules (such as an interface change in a module which requires a code change in another) commit from the trunk folder so that all changes are committed together.
- If possible, do not commit intermediate steps. Even if you're working on a change that might take a few days, it is preferable to commit the whole change as a whole. Subversion is a version control system, not a backup facility; if you're worried that you might lose your work, please take the necessary steps to avoid this on your computer. If for some reason you need to checkpoint your changes or to show them to another developer, you can use shelves: see this blog post for information.
- Conversely, do not commit unrelated changes in a single commit. For each change, take the time to identify the related files so that the set of modified files for each change can be committed separately.
- Use informative commit messages. Enough said.
Repository access
If you're using command-line tools, you can issue the command
svn checkout https://svn.code.sf.net/p/quantlib/code/trunkto check out the public repository.
If you're using some other tool, the actual steps might vary; however, the same URL can be used. Passing such URL causes Subversion to check out a copy of all modules (recommended for developers;) users wanting to check out a single module (e.g., QuantLib for the core library) can do so by appending the module name to the repository URL, e.g.,
svn checkout https://svn.code.sf.net/p/quantlib/code/trunk/QuantLib
If you have TortoiseSVN (for Windows) installed, with just one click you can check out the whole sourcecode or the core library.
Also, it is possible to browse the Subversion repository: this gives you a view into the current status of the project's code. You may also view the complete histories of any file in the repository.
Developer Access
The steps for checking out the repository are almost the same as for users, but with a different URL; developers with commit privileges will have to use
svn checkout --username=$USER svn+ssh://$USER@svn.code.sf.net/p/quantlib/code/trunkor
svn checkout --username=$USER https://svn.code.sf.net/p/quantlib/code/trunkinstead, where $USER is their Sourceforge username.
Note for C++ Unix users: if you use Subversion, you will need some GNU tools that usually only developers use, and which are not required to build QuantLib from tarballs. These are automake, autoconf, libtool, GNU m4, GNU make, and others which might escape me now. They all come with recent GNU/Linux distributions.
To begin the build process from a Subversion working copy, start with:
sh ./autogen.sh
which will prepare the package for compilation. You can then use ./configure and make in the usual way.