To access the qooxdoo SVN use the following command line:

svn co https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/trunk qooxdoo 

or your favorite SVN client with the following configuration:

• Hostname: qooxdoo.svn.sourceforge.net
• Port: 443
• Protocol: HTTPS
• Repository Path: /svnroot/qooxdoo
• Username: Your SourceForge.net username (only required for SVN write operations)
• Password: Your SourceForge.net user password (only required for SVN write operations)

Access to qooxdoo-contrib is quite similar:

svn co https://qooxdoo-contrib.svn.sourceforge.net/svnroot/qooxdoo-contrib qooxdoo-contrib 

Documentation on SVN is available, e.g. from Sourceforge. Comprehensive documentation can be found for different languages.

A command-line client is included with many operating systems (e.g. Linux, Mac OS X), it can even be installed for Windows (using the unix-like environment Cygwin.

Command-line tools may be powerful, but tend to be error-prone and often inconvenient to use, so you might prefer graphical tools:

• Eclipse (built-in SVN integration since v3.4), cross platform)
• TortoiseSVN (Windows)
• SCPlugin (Mac OS X)

There also is an overview of clients and plugins.

For the rest of this article we focus on the SVN command-line client. You need to have subversion installed locally. It is included with most operating systems (Linux. Mac OS X), or for Windows can be installed within Cygwin.

You’ll need to add a couple of config settings to your SVN config file. If you are on Windows, that’s located at:

C:\Documents and Settings\YourUserName\Application Data\Subversion\config

And on UNIX/Mac OS X:

~/.subversion/config

Open it up in your favorite text editor. Most configs have some default settings, so locate [miscellany] and enable-auto-props in the file. If they exist, make sure that they are uncommented (remove # from beginning of line), otherwise add them. The line should look like:

[miscellany]
enable-auto-props = yes

Next, locate the section [auto-props]. If it doesn’t exist, add it. If it already exists but is commented out, simply uncomment it. Add or modify the following entries below [auto-props]:

*.sh = svn:eol-style=native;svn:executable
*.py = svn:eol-style=native;svn:executable
*.txt = svn:eol-style=native
*.rest = svn:eol-style=native
*.css = svn:eol-style=native
*.xml = svn:eol-style=native
*.xsl = svn:eol-style=native
*.xslt = svn:eol-style=native
*.html = svn:eol-style=native
*.htm = svn:eol-style=native
*.htc = svn:eol-style=native
*.svg = svn:eol-style=native
*.js = svn:eol-style=native

*.png = svn:mime-type=image/png
*.gif = svn:mime-type=image/gif
*.jpg = svn:mime-type=image/jpeg
*.jpeg = svn:mime-type=image/jpeg

Makefile = svn:eol-style=native
README = svn:eol-style=native
CHANGELOG = svn:eol-style=native
LICENSE = svn:eol-style=native
AUTHORS = svn:eol-style=native
RELEASENOTES = svn:eol-style=native
TODO = svn:eol-style=native

Below the Subversion repository path https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/ the following folder structure exists:

  branches/
     legacy_0_1_x/*
     legacy_0_5_x/*
     legacy_0_6_x/*
     legacy_0_7_x/*
     ...

  tags/
     release_0_1/*
     ...
     release_0_6_6/*
     release_0_6_7/*
     ...
     release_0_7_3/*
     release_0_7_4/*
     ...
     release_0_8/*
     release_0_8_1/*
     ...

  trunk/*

Each of the folders marked by a trailing * contains a folder qooxdoo/ that holds the corresponding SVN version of the framework. The meanings of the three categories are:

This is the place where most of the actual development of the framework happens. Development activity for qooxdoo is high, so there are often many commits just within a few minutes. As a consequence, such a snapshot of the trunk is not always stable. It is usually not recommended for production use or as a starting point for learning how to use qooxdoo.

Having just said that most of the development happens in the trunk, all remaining development activity usually takes place in temporary branches. The convention is to start their name with devel_. Such branches are supposed to exist for only a limited period of time. They often function as isolated playgrounds that would otherwise render the trunk version unusable for a longer time. Such a devel branch is removed from SVN once the results have been merged into trunk or another branch, or if the results were not satisfying.

Folders that start with legacy_ are available for a (reasonably) unlimited time. Such a branch is often created when a new release is published, but work on the next major version needs to be started. The legacy branches then continue to be used for developing the latest stable “line” of code, e.g.”legacy_0_7_x” for a next version for the “0.7” line.

If contributors are interested in further development of such a legacy line, they should (if appropriate) commit changes to both - the line in question and the trunk. Bugfixes only relevant for the legacy line ought to be committed exclusively to the line in question.

It is recommended to keep updating your custom applications with each new stable qooxdoo release. Built-in migration support usually helps a lot, so it is recommended to invest time into migrating custom applications rather than bugfixing outdated qooxdoo releases.

All official releases are permanently available under the tags/ folder. They may be checked-out individually. Those tags are are regarded “read-only” and must not be changed after the corresponding release.

Please execute the following shell command to checkout the latest development version of qooxdoo (the so-called SVN “trunk”). The appropriate files are transferred from the remote Subversion repository into a local directory named qooxdoo:

$ svn co https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/trunk/qooxdoo

To checkout a specific branch or tag please use the following commands (<name-of-...> being placeholders). The optional last argument specifies the target directory. It is a good practice to put the branch/tag name dot-separated after the project’s name:

$ svn co https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/branches/<name-of-branch> qooxdoo.<name-of-branch>

or for tags:

$ svn co https://qooxdoo.svn.sourceforge.net/svnroot/qooxdoo/tags/<name-of-tag> qooxdoo.<name-of-tag>

After a successful check-out you will find a folder structure on your hard-disk that is similar, but not equal to the corresponding SDK structure. This is due to the fact that the SVN sources are the input data for the process that eventually creates the SDK, applying some transformations along the way.

Here are various hints that should help you get oriented:

• Independent of the version you have checked out you will find a few elements that should be familiar from the SDK:
  • framework classes, usually under a framework/ folder
  • standard applications, like feedreader and apiviewer
• You can (and this is probably the biggest use case for SVN) use the check-out to generate your custom applications with, by setting QOOXDOO_PATH in the app’s configuration to the path leading to the check-out folder (details where the path should end might vary a bit from version to version; check the version’s documentation, or poke around in one of the standard apps’ config). If you then run targets in your custom app like source or build, the checked-out files will be used (class files, configuration files, etc.), so you are “running against” the SVN version.
• The check-out also contains various files that pertain to the project’s site management, like for running test environments, maintaining the qooxdoo web site, or, of course, creating the SDK. These will usually not be relevant to you.
• Particularly, you might come across index.html files near to the top of the check-out, which will probably be of little use to you because they reflect the situation of the SDK and not that of the SVN tree. Index files in the standard applications, on the other hand, are usable after the appropriate build command has been run.

In general, keep in mind that the SVN environment is a workbench, so it follows a different philosophy than the SDK, and is usually undocumented as all these efforts go into the SDK documentation. If you have questions, ask them on the mailing list.