JoomlaLogo I am developing for Joomla! now since the beginning but I was always disturbed by
the way people are using the code repository of Joomla! (
I am doing professional java development but was never able to reproduce the way
I am working nor really did take the time to really do it correctly (help by the fact that I
was developing always alone). Things changes... and now I am part of the effort of
bringing JoomlaComment to run natively in Joomla! 1.5 in a team of 3 people.

What people are doing, most of the time, is committing the code they write to Joomla
SVN/CVS in a flat way, it is just a set of files, or sometime even only the deliverable
(a set of zip that user can install)

So these kind of subversion layout are not uncommon

A set of files A set of directory containing just different code version and code exploded Just one version exploded in root
layout A layout B layout C


All of these layout are highly not efficient...The point of SVN/CVS
is to&160; compare and synchronize code easily (you merge code nearly 40% of your time
as a developer), and resolve code conflicts. SVN only store differences so sync is fast
and repository size is very low.

Subversion&174; is an open-source version control system. Subversion&174; allows developers to share
there projects on the repositories, where they are stored afterwards. Repository is much similar
to a file server, except the fact, that it not only stores the copy of the file system, but its previous
states and changing history. Subversion&174; access its repositories using network, so it provides a
probability for a person to work over some shared files and watch for every possible changes made
by other developers.

With all of the above layout A, B or C, the code committed is not connected to the runtime
where you are developing!

The developer runtime is a running Joomla instance, and developer change their code directly
in the file system of Joomla!. If you work in a group, you'll be force to connect another project
with the layout&160; A, B or C and merge code change manually from the local Joomla! instance to the shared


Recommended SVN layout

I am now using the recommended SVN layout:&160; /trunk /tags /branches

Trunk is a main (head) line of development. That's where you share your project and do initial commit.
The code in trunk is considered not stable or in development. Usually nobody&160; should commit code which
break the trunk (to know it there is nothing else better than regression testing and continuous build server)

is a snapshot of the project state. You can create a tag of the one specified revision or a tag, containing
resources of different revisions. Tags are a kind of specific labels for a set of files each with its own revision
number. Used to track the important events if project's life cycle.

Branching means creating a new line of development on the repository location. This may be useful in
a different cases, for example if different clients wish to get the same product but with some differences
in functionality. Of course it's not convenient to create both products from the beginning to the end
separately, so the developers create branches. Branches are the additional lines of development.
Used when branching for different versions from one initial is needed or when each developer has his
own development line and plan.

I recommend you using Eclipse PDT (free),&160; So I have created 2 new PHP project in eclipse:
ff0000">securityimages4 (Joomla! 1.4) and ff0000">securityimages5 (Joomla! 1.5). For eaxmple ff0000">securityimages5

  • Contains Joomla 1.5.3, my code is sometimes highly dependent on a specific Joomla API version,
    or may break if Joomla! release a new version, so it has to be tested against some specific version of it
  • Has the latest version of securityimages installed&160; (5.0.0Rc1)
  • Has a MYSQL dump securityimages.sql which create a DB securityimages4 with its data, so anybody can have
    a running environment just by doing a checkout from trunk
  • Has an ANT build file, more on it later.


This project is fully versioned (so even Joomla! and MYSQL dump). What could be disturbing at first but make sense
to version also the container (Joomla!) where your code run.

Carefully commit

While working in a team, not all file has to be committed to /trunk

The configuration.php for example is a default one (mine), anybody can make change but shall not commit it to the trunk! ->
Not all developer use XAMPP at the same location or may use another DB user (this is another topic among a team of developer:
standardize developer environment). I've commit dummy login/password for administrator panel is admin:admin
The login for MYSQL in&160; configuration.php is root: empty.


When I develop, alone or in a team, I do daily before every change a Team synchronize on project securityimages4 in order
to see what has changed or who has done what and on which lines.

I it highly recommended not to update without looking at what is coming from SVN, so anybody can give give feedback on
code quality better if you look at it), you get update from the trunk, or commit your new code change to the trunk.

As soon as I have no visible bug and all functionalities, I create a new release

Create a new release

When I want to make a new release, I launch in eclipse an ant build&160; (right click &8211; run as ant build on / securityimages4/build.xml)

This create the deliverable (a component zip or N files as zip with a version number) that I can publish/version also in another project
or NOT version at all since I can at any time load a project tag of securityimages4 and recreate the deliverable build!

The deliverable are what I publish on my site.

The ANT build file look like:

   1:  <?xml version="1.0" encoding="UTF-8"?>
   2:  <project name="securityimages" default="_build">
   3:  <description>Create a new release of joomla component</description>
   4:  &160;
   5:  <property name="workspace.dir" value="." />
   6:  <property name="component.version" value="5.0.0RC2" />
   7:  <property name="" value="securityimages" />
   8:  &160;
   9:  <property name="destination.dir" value="c:\temp\${}-${component.version}" />
  10:  &160;
  11:  <target name="_preparedirs">
  12:  <mkdir dir="${destination.dir}" />
  13:  </target>
  14:  &160;
  15:  <target name="_build" depends="_preparedirs" description="deploy joomla component">
  16:  <copy todir="${destination.dir}/components" filtering="on">
  17:  <fileset dir="${workspace.dir}/administrator/components/com_${}" includes="**/*.*" />
  18:  <fileset dir="${workspace.dir}/components/com_${}" includes="**/*.*" />
  19:  <fileset dir="${workspace.dir}/plugins/seystem" includes="${}.*" />
  20:  </copy>
  21:  <copy todir="${destination.dir}/plugin" filtering="on">
  22:  <fileset dir="${workspace.dir}/plugins/seystem" includes="${}.*" />
  23:  </copy>
  24:  </target>
  25:  </project>

Its purpose it to build a new deliverable in one click without going through the file system over and over.

I also version the project ff0000">securityimages5 with the same version number, so I can then continue developing in trunk.


Branching an existing release

If someone report an issue, lets say in and code in /trunk is too far away in trunk or still unstable
to be released, I make a branch on project ff0000">securityimages5&160;

I load the tag version 5.0.1 of the project ff0000">securityimages5&160; in my eclipse workspace (Team replace with - tags) and open
a branch (Team &8211; open branch)&160; and this project is now suddenly similar to another trunk:

  • A branch is not unique and is reacting like a trunk
  • The tag 5.0.1 still exist and is read only
  • I can now can commit new code in the branch (= to a trunk)
  • The main /trunk still exist and is not touched

When all issues are solved, after many commit to the branch (= to a trunk), I version the branch with a &8230;. Tag, for example
5.0.2&160; which is a normal tag and represent a new stable state in the lifetime of the software.

Nasty back porting

Somehow a bug in version 5.0.1 has a lot of chance of also being in the latest version (the code in /trunk). So I am forced to
load the trunk (= current code) and make Team &8211; compare with &8211; another branch &8211; tag version - 5.0.2 and back port all code
changes in trunk if it make sense.

Remember a tag should never be change, it is possible to overwrite tag, but this should occur 0.000001% of the developer lifetime.
A tag is a freeze code status from the past and the past can not be change ;-)

Joomla Releasing new versions

Joomla release a new version? I install the new version of Joomla! in my eclipse project ff0000">securityimages5 If securityimages still
work, nice! if not I make changes for that version of Joomla! and create a &8230; new tag of securityimages.




You are now able to compare the trunk with any working/non working versions (tag or branches) of the past. See what has committed what
and where in the file system of Joomla! and this by using the merging client of Eclipse SVN/CVS client which is way more efficient than any diff
for merging code. This were before with version directory in Subversion (SVN/CVS) not possible.&160;

You might like also

Announcing Module nimbus for all users of Phil Taylor Joomla! tags
I am a very happy user of Joomla! tags from Phil Taylor. My only complaints is that it is still not part of #Joomla!® core. Joomla!® Tags is a #Joomla Extension for adding tags to #Joomla!® Content. Use Joomla Tags to allow content classification by keywords (Tags), can also be used to create virtual categories to add content into, over coming #Joomla!® single section/category structure read more here…         …
3725 Days ago
Content plugin for Joomla! 1.5 to embed Freemind Mind Map in your articles
I offer You now a new plug-in for #Joomla! 1.5 that allow you to display any Freemind Mind Map using a fancy Flash applet in article content. You can put anywhere in your article the following keywords This #Joomla! plugin use Freemind Flash Browser:   You can see the flash browser in action (full screen) here …
3725 Days ago
Joomtwitter a twitter module for Joomla!
Twitter is a free service that lets you keep in touch with people through the exchange of quick, frequent answers to one simple question: What are you doing? A very simple module with a great output layout that require flash 9 for properly operations. I use it on my site (at the bottom) it output valid XHTML 1.0 Strict Since it is a #Joomla! module, it is easily customizable and can be place anywhere in your #Joomla! template It allow …
3877 Days ago
No Thumbnail was found
As I found no better tutorial on Internet, here is a very very short how to add Google analytics to Atlassian JIRA Edit the file atlassian-jira/includes/decorators/stylesheettag.jsp This file is responsible for adding CSS links in html and is included in all pages. Now put the usual code you get after creating a new analytics profile <script type="text/javascript"> var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www."); document.write(unescape("%3Cscript src='" + gaJsHost + "' type='text/javascript'%3E%3C/script%3E")); </script> <script type="text/javascript"> try catch(err) </script> …
3998 Days ago
New JIRA Bug Tracking system for all my Joomla! components!
I am very proud to announce that I got granted a JIRA and Bamboo Open Source license! Extract form their site: Open Source Atlassian supports and believes in the Open Source movement - JIRA utilises a number of good Open Source components, and Atlassian developers are committers on a large number of Open Source projects. To give back to the open source community (and hopefully improve the quality of those projects!), JIRA is free for any Open Source project to …
4000 Days ago
No Thumbnail was found
Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily - leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing …
4069 Days ago
Converting your component from Joomla 1.0.8 to Joomla 1.1.X
I am currently in the process of moving all my open source project (7!) in CVS Head to the latest #Joomla API 1.1.X. I've tried to summarize in the following table some conversion rulesIn #Joomla 1.0.Xhas to be converted in #Joomla 1.1.XWheremosMenuBar::startTable();JMenuBar::startTable();PHP codedefined('_VALID_MOS') or die('Direct Access to this location is not allowed.');defined( '_JEXEC' ) or die( 'Restricted access' );PHP coderequire_once( $mainframe->getPath( 'toolbar_html' ) );require_once( JApplicationHelper::getPath( 'toolbar_html' ) );PHP code<?xml version="1.0" encoding="iso-8859-1"?><mosinstall type="component" version="1.0.0">....<?xml version="1.0" encoding="iso-8859-1"?><install type="component" version="1.0.0">....Installer XML fileMore to …
5053 Days ago
Access to Joomla CVS forge using eclipse
I show You here (with screenshots) How to access #Joomla Forge CVS system using the standard Eclipse CVS client. Click Read more ! …
5054 Days ago