[Show/Hide Right Column]

This page is to document "what Tiki should do". For feature documentation (what Tiki does), please see corresponding page on doc site

Distributed revision control

We are staying on SVN for the forseeable future but there is a maintained Git mirror at https://github.com/changi67/tiki/
Some notes about this are here Using Git with Tiki

This page is to discuss and if decided, coordinate the eventual transition to a Distributed revision control system (DRCS). Tiki started in 2002 with CVS and switched to SVN between 1.9 and 2.0 The current situation with SVN is good and there is no emergency to change. This is just to explore any new opportunities.

We have not decided to switch to DRCS and we have not decided not to switch. If ever we do switch, the software is not picked. So for the forseeable future, all developers interested in using Git should go right ahead and use it and commit to the main repository using git-svn. The best of both worlds!

We should take the time to pick the best system for our model. Sometimes, a DRCS is introduced to provide more flexibility to "non-core developers". In Tiki, since all devs have commit access to the whole code base, this doesn't provide us with the same "advantage" as it would another project.

Rodrigo Primo wrote:
I have been using a local copy of Tiki repository created with git-svn for almost two years now. It is not the same as having the whole project using Git, but in my opinion, for development purposes, is much better than SVN. You can use most of the nice Git features like git blame, git stash, git bisect just to mention a few.


Why not

  • Developers (such as Rodrigo) can use and benefit from Git and commit to SVN, without affecting the workflow of everyone else (we have 500 accounts on SourceForge.net)
  • Is the effort worth it?
    • It's a lot more work than many people may think. Tiki is a large project, and there are many scripts and setups. The migration to Allura should have been very simple because it's' mostly just about changing the repo location, but it caused extra work for developers.
  • Is it harder to use than SVN?
    • With SVN, you need to keep in mind 3 versions of a page:
      • BASE version (i.e. the version that was in the repository last time you updated it)
      • LOCAL version (i.e. the version you have on your machine)
      • HEAD version (i.e. the version that is at the HEAD of the SVN repository)
    • With a DVCS, you have to keep in mind 5 versions:
      • LOCAL BASE version (i.e. the version that was in the LOCAL repository last time you updated it)
      • LOCAL LOCAL version (i.e. the version you have on your machine)
      • LOCAL HEAD version (i.e. the version that is at the HEAD of the LOCAL repository)
      • REMOTE BASE (i.e. the version that was on the remote repository the last time you imported it to your local repository)
      • REMOTE HEAD (i.e. the version that is at the HEAD of the LOCAL repository)

Minimum criteria

  • Needs to be offered by SourceForge.net
  • Need a read-only from SVN so shared hosting environments can easily update
  • Need a multi-platform client because we have developers on each.
  • Moving away from SVN means updating the release scripts, TRIM and our Continuous integration infrastructure, which is significant work.
    • Thus, the person that leads the migration efforts would also take the lead to update all the release scripts.
      • A beta of the new release scripts should be available long before the official migration to the new system, because we need to make sure not to delay the release.
        • This person will be the package manager and be responsible for the merging process until it's stable.


  • Help address other needs such as
    • Web commits
      • This would increase collaboration from translators and theme designers
    • Improving Code Review workflow to reduce time investment of the Quality Team
      • So tool should have code review or let us integrate with code.tiki.org
    • Continuous Integration
    • Ease Version lifecycle (maintenance of 4 active branches)
      • Better merging would be nice, especially translations
  • As much support as possible from integrated development environments (such as XAMPP-Aptana) (Eclipse has a Subversion plugin)
  • As much support as possible from operating systems (Windows has TortoiseSVN, GNU/Linux has kdesvn for KDE)

If so, when

If so, which one?


GIT seems to be a powerful alternative to SVN and there are some plans to integrate it into the current development system. We don't want to migrate to git, but rather mirror svn in git. See - https://github.com/alloy/git-svn-mirror

Linus on git


A plugin exists for the Aptana Studio IDE




Android ports



  • How to deal with externals from Git or SVN?


  • Simple to deploy (one file for the app, one file per repository)
  • Works on shared hosting
  • Fossil Bisect





Spaces [toggle]

Search Wishes (subject only) [toggle]

Keywords [toggle]

The following is a list of keywords that should serve as hubs for navigation within the Tiki development and should correspond to documentation keywords.

Each feature in Tiki has a wiki page which regroups all the bugs, requests for enhancements, etc. It is somewhat a form of wiki-based project management. You can also express your interest in a feature by adding it to your profile. You can also try out the Dynamic filter.

TogetherButton [toggle]

Documentation: PluginTogether