| This article (or section) needs work.|
Running Unreleased (svn) versions of SiT
The very latest bleeding-edge version of SiT is the svn version which normally resides in trunk of our svn repository. It's there for developers to work on the code and we don't intend that anybody tries to use it for anything serious, much less for production use. But it is useful for anybody who wants to have a look at the code or try out a feature on a test machine or even to help with developing SiT.
Since SVN versions are, by their very nature, unfinished, it's not always easy to get them up and running.
This page is not intended to have all the answers, but these tips may help you get started.
- Don't ever try and use an svn version in a live/production environment, these are for testing/development only, you have been warned
- You are unlikely to get assistance in our forums or on our irc channel if you are using an svn version in a live/production environment. Unless your purpose is development.
- First make a backup of your SiT files and database (if you have an installation already)
- Checkout the source from SVN, development normally proceeds in trunk, but you may want to check with the developers on IRC to make sure you're getting the latest code
If you are upgrading
Open up the file
setup-schema.php in your text editor and look towards the bottom of the file, there will be a section labelled
$upgrade_schema where 999 is the version number that is currently being developed (e.g. 341 for v3.41). You will need to execute these SQL commands manually (via phpmyadmin is the easiest way). Unfortunately we use variables for the table names, so you'll have to edit each line first. For example
$dbUsers needs to be changed to
users - Of course if you're using a table prefix you'll have to add that as well, so it may be for example
sit_users. (Who said this was going to be easy).
You will more than likely find bugs when running the svn version, plenty of them. It's not always helpful for you to log these in our bug tracker since many of them will already be known. The best thing to do is to discuss them with developers on IRC first. Don't expect us to fix the bugs straight away, we need to prioritize which bugs we fix in which order so that the development schedule can follow a plan.