NewsFeaturesDownloadsDevelopmentSupportAbout Us

Subversion Repository

From LifeType Wiki


The Subversion Repository

The most bleeding edge development of pLog is kept in our Subversion repository hosted at Subversion is a very powerful replacement for CVS, which is already being widely use in many other open-source projects.

The development version is updated almost daily and it might be that it is broken from time to time, maybe because the development made some big changes or maybe because we did not even notice when we committed the code. Nonetheless, it should work most of the time.

Getting a Subversion client

Most Linux distros come with the command-line Subversion client (svn) already installed, be sure to use a recent version of subversion (version 1.0 and beyond). If you're using MacOS X it can be easily installed via Fink or Gentoo for MacOS. In Windows, there are other alternatives such as TortoiseSVN

Organization of the Subversion repository

The repository is organized in the following different modules: plog, plugins and templates. Each one of the modules has different contents but inside the module, they all follow the same structure:


The top level folder is called plog and that is where all the other modules are located. The plog module contains the core code of LifeType, and it is still called "plog" (LifeType's former name until early 2005) for historical reasons. plugins contains the code for all the plugins available and templates contains all the different templates available.

Inside each one of the modules, the structure is as follows:

  • trunk is the main folder and it will usually contain the most recent version of the data. So in the case of the *plog/trunk* folder, it will contain the latest development version of each one of the files that make up pLog.
  • branches contains any code that was branched from the main trunk. The concept is perhaps a bit difficult to understand, but there are two ways we use branches.
    • One is that sometimes developers need to work on new features that might keep the trunk broken for a long while (big internal reorganizations of the code, for example) so instead of keeping the development version broken, they will just "create" a branch with the current version of the code and place it for example in plog/branches/lifetype-big-changes. The developers would work separately on that branch until it is not broken anymore and by doing so, they won't interfere from other people's development tasks. Once the branch is stable, it will be merged with the code in the trunk (all this merging and branching is handled transparently by Subversion).
    • The other way we use branches is for working towards a stable release, where the trunk/development version undergoes more active development on longer-term goals, the branches (such as the 1.1.1) only contain bug fixes and smaller feature requests. For example, the 1.0.5 and 1.0.6 branches only contained security updates, and probably most of the development team didn't actually use these branches on their own blogs, because the 1.1 trunk was close to release, and so was already stable enough. However, most users would not have been using the development trunk, so we had to release the bug fixes for 1.0.4, and so released them as 1.0.5 and 1.0.6. Arguably, since the changes were so small, we could have made the changes on the 1.0.4 branch (since the 1.0.4 tag was already created, see below), and we could have just added 1.0.5 and 1.0.6 tags instead, but since subversion can copy whole branches without using any disk space, it is clearer to make new branches.
    • Shortly before a release date, the trunk is quite stable, as that is the version the developers generally use on their own blogs, but just after a release, probably you don't want to use the trunk, but instead use an appropriate branch.
  • tags Whenever a new release is made, a new tag will be created in this folder. A tag is basically a snapshot of the repository at a certain point in time (usually in the past :)) This allows to easily retrieve previous versions of pLog.

For practical purposes, end users who wish to take a glimpse at the latest development version do not need to worry too much about anything else than the trunk branch.

Checking out code

Using the Subversion command line client, run the following command to checkout the code from the trunk/ folder (which will usually contain the latest development version - which isn't guaranteed to be stable, so only do this if you are sure you know what you are doing):

 svn checkout

If you wish to check out a certain branch or tag, replace /trunk with /branch/branch-name or /tags/tag-name:

 svn checkout

(/tags/lifetype-1.1.5 actually exists, the repository already has snapshots of all the official versions of LifeType so far)

Running svn checkout will create some files and folders in the current folder.

Please be careful when checking out code unless you want to check out the whole repository. We don't really care how much you check out, but you will probably end up downloading a huge amount of data. The example above (/svn/plog/plog/trunk) will check out the latest development version, but something like this:

 svn checkout

will check all the folders below /plog/plog which include, and always according to the structure described above, /trunk, /branches and /tags. 'The /branches folder is quite a heavy one since includes every single version from LifeType 1.2 to LifeType 0.3.2

Updating your code

In the same folder where the code was checked out for the first time, run the following command whenever the code should be updated to the latest version available:

 svn update

Subversion will attempt to merge any local changes that may have been made. If the local changes conflict with changes in the newest versions of the files, Subversion will not remove your version of the conflicting files but will let you know about the conflicts. See the Subversion documenation for more information on how to deal with conflicts.

Browsing the repository with a browser

Subversion generates XML code that can be browsed with any browser that supports XML and XSLT (such as any fairly recent version of Mozilla and Internet Explorer) The default XSLT template used by Subversion is very simple and only allows to navigate through the browser structure and see the contents of files, but it is not possible to see older revisions of files (if you know how to create a better XSLT sheet for Subversion, please let us know)

In order to take a look at the repository without downloading any file, point your browser to the following address:

(or any other valid folder in the repository such as


If you get error messages like:

svn: REPORT request failed

upgrade your subversion. most likely you're using an outdated subversion client. You can check your version via

svn --version

make sure its at least version 1.

Subversion and Squid

These types of errors may also be due to your proxy server setup. In order to allow SVN through Squid proxy servers you'll need to add the following to your squid.conf file.


This allows the non-standard HTTP methods subversion uses to communicate correctly.

Keeping your source code changes up-to-date with the development tree

It can be a tricky process, keeping local changes in sync with changes from the developers. Fortunately, there is an excellent solution, by using SVK, an extension (of sorts) to subversion. SVKConfig

Additional information

There is an excellent book online, freely available, about Subversion: Version Control with Subversion

Getting write access to the repository

Treat Oscar real nice. (:

Guidelines for committing code


Getting an email message after each commit

The is a mailing list where a message is sent after each commit is made to any of the repository modules. The message includes a list of all the files that were changed in the commit as well as a basic, raw diff of the changes.

This list is also a place where developers discuss development topics that would not fit anywhere else.

Please subscribe to the list via Mailman's web interface:

Maintaining a local copy of the project's repository via SVK

Svk is a decentralized version control system based on Subversion. It has successfully been used to keep local source code trees with customizations synchronized with the project's Subversion repository.

There is a more detailed description in the SVK page.