James Titcumb

At our company we currently all work on one shared network drive. The source code is not under any kind of source control, which for me is a big no-no. I’d love to be able to set up SVN and us all work of separate repositories and just commit back to a trunk or branch, but our tech manager doesn’t agree. The way I see it, there are two major issues:

• The source has no history – if there is a problem, we can’t roll back
• We overwrite each other’s changes if we work on the same file

How do other people manage this situation? Having source control on the network drive is fine, but that doesn’t solve the problem of overwriting each other’s changes does it… And setting everyone up with VMs or local repos doesn’t wash with the tech manager. Would a solutions such as each having their own checkout and then the shared network drive automatically update work? What about slowness in updating – people making a change and having to wait a while before it takes effect probably wouldn’t wash with our tech team, and committing back every tiny change seems a bit silly.

What about other source control (i.e. not SVN) – do you think it would suit us? I’m open to suggestions, except for Visual SourceSafe. Preferably something that integrates well with Eclipse, and is also cross platform (we use a mix of Windows, OSX and Linux), but something that also works well without Eclipse… tall order perhaps?

Whenever I tried to get CollabNet for Eclipse plugin working in Eclipse PDT, it always failed, yielding the error “Unable to load SVN client” upon any SVN activity. I did endless amounts of Googling to try to solve the problem, but always came to a brick wall.

The big problem here is that Eclipse is just too new for Ubuntu – even Jaunty. An apt-get install subversion on Jaunty Jackalope will install subversion 1.5.4, which just doesn’t work, and thats where the big problem lies. CollabNet for Eclipse categorically requires Subversion 1.6. Unfortunately the only solution I’ve come up with is to compile subversion and it’s javahl bindings yourself. I’ll try and remember all the steps I took to make it work.

First, download the latest subversion and subversion-deps tgz from http://subversion.tigris.org/. At time of writing they are here and here. Extract them both:

$ tar zxvf subversion-1.6.1.tar.gz
$ tar zxvf subversion-deps-1.6.1.tar.gz
$ cd subversion-1.6.1

You’ll need to install a couple of extra packages (this assumes you’re using Sun’s JRE), and assuming you already had subversion and libsvn-javahl already installed, uninstall a couple:

$ sudo apt-get install libssl-dev sun-java6-jdk g++
$ sudo apt-get remove subversion libsvn-javahl

Configure, make and install subversion. You can check it’s the right version too:

$ ./configure --disable-nls --enable-javahl --with-jdk=/usr/lib/jvm/java-6-sun-1.6.0.13
$ make
$ sudo make install
$ svn --version

Once that’s done, you’ll want to compile the javahl binding. Once installed, check it’s installed correctly too. It’s fairly likely the .so file will be in /usr/local/lib.

$ make javahl
$ sudo make install-javahl
$ sudo updatedb
$ locate libsvnjavahl-1.so
$ sudo ldconfig

Open your eclipse.ini, and after the -vmargs line, add:

-Djava.library.path=/usr/local/lib

replacing the path with the path where the libsvnjavahl-1.so with your correct path.

Now fire up Eclipse, go to Window > Preferences > Team > SVN. The SVN Interface should now say JavaHL (JNI) 1.6.1 and a revision, depending on the particular version of SVN you installed.

I think that’s all the steps I took, so I apologise if I missed something out – if I remember something I’ll add it in!

Update: Compiling javahl requires g++, so I added that into the apt-get install line.

Update 2: Missed out ldconfig after libraries creation.

Update 3: If you still have issues getting it to work, I recommend looking at http://subclipse.tigris.org/wiki/JavaHL, reading it carefully, especially the Troubleshooting on Linux section. The javahltests.jar JUnit tests that are provided on the page may be very handy when debugging problems!

UPDATE!!

For the new Zend Framework 1.8.x series, please refer to this article. This is still here for historical purposes.

This is a pretty simple howto, but here it is anyway!

I assume already that you’ve got a LAMP stack working, and if you don’t, it’s easy as pie to install one in Ubuntu:

sudo tasksel install lamp-server

So now you’ve got your LAMP stack up and running, lets download the latest SVN tag of Zend Framework. At the time of writing, the latest stable is 1.7.8, which I’ll use here. If you want to check for the latest version, visit http://framework.zend.com/svn/framework/standard/tags/ in your browser, and the last folder is the one you want. If you want stable full releases, ignore the RC/PR versions. So, once you’ve determined the version you want, we’ll check out the release:

cd /usr/share/php5
sudo mkdir ZendFramework
sudo svn co http://framework.zend.com/svn/framework/standard/tags/release-1.7.8/

It is likely you’ll need to use sudo for these commands as /usr/share/php5 is owned by root by default. You’ll see a big long list of files being checked out, and once that’s done you’ll have a new folder appropriately named “release-1.7.8″. Create a soft link called “current” to the release folder so you can change the default included Zend Framework version without restarting Apache in the future:

sudo ln -s release-1.7.8 current

You can stop there if you like, and manually add the include path into your PHP scripts using set_include_path. However, if you would like the current Zend Framework included automatically, then continue by opening /etc/php5/apache2/php.ini in your favourite editor. Add the path to your include_path list. For example, if your current include_path is (and this is the default):

include_path = ".:/usr/share/php5:/usr/share/pear"

Then change it to:

include_path = ".:/usr/share/php5:/usr/share/pear:/usr/share/php5/ZendFramework/current/library"

All you need to do now is restart Apache:

/etc/init.d/apache2 restart

In the future, if you wish to change to a new default Zend Framework version (for example 1.8.0), then just check out the SVN directory and change the soft link. You won’t even have to restart Apache, and the changes will take effect immediately! For example:

sudo svn co http://framework.zend.com/svn/framework/standard/tags/release-1.8.0/
sudo rm current
sudo ln -s release-1.8.0 current

If you want to keep up to date with the latest Zend software, then just subscribe to their RSS feed!

I’m really growing to love Eclipse (specifically PHP Development Tools, the PHP extension for it), and how versatile and useful a work environment it is. It really does have everything, and it really helps you get on with what you need to do, when you’re not blogging that is… Now I know why developers have been raving about Eclipse all this time.

One thing I learned today is the huge importance of Perspectives and Views in Eclipse. When Kelvin first said “right, stop using PhpEd, and use this Eclipse thing”, I was overwhelmed by the feature-richness, and my knee-jerk reaction was to just set it up as close to the way I used PhpEd. Thats the first mistake I made, because although I got it close, I missed out on all the glorious features I could’ve been using.

Our Eclipse configuration at work uses Eclipse, PDT, Mylyn, SVN and CollabNet – which integrates wonderfully into our Sourceforge 5.0 server. Mylyn and CollabNet allow task management and allows me to work on Sourceforge artefacts within the Eclipse environment. A rather cool feature is contexts, which allow me to basically attach a list of files to the SF artefact, and when I activate the task in my Task List (note, not “Tasks”, “Task Lists”, a part of Mylyn), it opens all the files I was working on.

Because of our heavy reliance on SourceForge (everything we do has an associated artefact), it makes sense to make use of the CollabNet perspective. If I want to go into “task management mode”, i.e. line up a load of work that has been assigned to me, I switch to the CollabNet perspective. I open an artefact from my assigned artefacts list in the CollabNet view, and it automatically adds it to my Mylyn Task list. I can then say “right, I’m working on this one”, and click a little blob which turns blue, and then I’m working on it. If I’ve been previously working on it, and I attached the context, it automatically opens the files I was working on.

This was meant to be a short homage to Eclipse, but has turned into a little rant, but now that Kelvin set up the SVN repository on Friday properly, we’re actually FINALLY using source control, after the months of me (and Chris) nagging him to get it set up. It’s a little step, but we’re working on the same checkout at the moment, but eventually all that will change. I’ll start bugging him for that soon…

Anyway, if you’re a PHP developer, on a Mac, Windows or Linux, and you’re not using Eclipse PDT yet, I strongly suggest you do so. It’ll make your productivity increase hugely – it did mine!

I had a handy mechanism working on my old old CVS server, and I’ve been using it for some time on my current SVN server.

Basically, whenever you commit a file to the repository, if you have a checked out workspace on the same server, then it will automatically update to the latest revision of the checked out branch or trunk. It’s handy so you don’t have to “svn up” every time you make a change, especially if you’re making lots of tiny changes.

This guide was original from Marc Grabanski‘s blog, so 99% of credit goes to him.

cd /svnroot/hooks/
cp post-commit.tmpl post-commit
chmod +x post-commit

You can make a little program to update all your SVN repositories, so nano svnupdate.c:

#include <stddef.h>
#include <stdlib.h>
#include <unistd.h>
 
int main(void)
{
  execl(
    "/usr/bin/svn",
    "svn",
    "update",
    "/path/to/mywebsite1.co.uk/www/",
    "/path/to/mywebsite2.co.uk/www/",
    "/path/to/mywebsite3.co.uk/www/",
    (const char *) NULL);
  return(EXIT_FAILURE);
}

You can add as many paths as you like there, just copy and paste the line and edit the path to your needs. You need to then compile it, test it.

gcc -o svnupdate svnupdate.c
env - ./svnupdate

Nano your post-commit file and add in the FULL path to your svnupdate program:

/path/to/svnroot/hooks/svnupdate