Monthly Archives: October 2009

The Power of svn externals

I have a list of svn tricks over on a previous post, (my) Essential Cheat Sheet of Shell Commands. But I was listening to a very lengthy, and I mean really lengthy Zend podcast, over two hours in length: The ZendCon Sessions Episode 26: Best Practices of PHP Development, with Matthew Weier O’Phinney and Mike Naberezny. I learned a new trick about subversion I would like to share and note here for the future, svn externals .

I had of course heard of svn externals before but a little explanation really enlightened me. You can multiply your power as a developer with svn externals. Alongside your own project under svn control, you can add in other remote projects from remote svn repositories with the svn propset command and they will naturally remain current as you run updates on your own repository.

You can multiply your power as a developer with svn externals.

In the struggle for project housekeeping it can be a chore to keep libraries, plugins, middleware, and other goodies up to date. In general we as developers have a mindset about keeping a project managed by version control, but its an idea that I have seen stopping at the project in question. The project is under svn, the rest of the libraries are from static resources like tarballs. By just extending the power of version control just a little bit further, we have a big labor saver, and we are opened up to the great universe of software. Svn externals gives us mighty lever, because we then have the power to keep in step with all of the other bits and pieces that go along with a project.

Your main project is under version control, but your rich html editor, TinyMCE, is not. Well it can be. Lets use it as an example.

test$ mkdir tmc
test$ cd $_
test/tmc$ mkdir html
test/tmc$ mkdir project
test/tmc$ cd $_
test/tmc/project$ mkdir branches tags trunk
test/tmc/project$ cd -
/home/pbg/websites/test/tmc
test/tmc$ cd html/
test/tmc/html$ ls
test/tmc/html$ emacs index.php
test/tmc/html$ cd ../
test/tmc$ cp -rf html project/trunk/
test/tmc$ ls
html  project
test/tmc$ ls project/trunk/
html
test/tmc$ ls project/trunk/html/
index.php  tiny
test/tmc$ ls
html  project
test/tmc$ rm -rf html
test/tmc$ ls
project
test/tmc$ svnadmin create tmcrepository
test/tmc$ svn import project file:///home/pbg/websites/test/tmc/tmcrepository -m "initial import"
Adding         project/trunk
Adding         project/trunk/html
Adding         project/trunk/html/index.php
Adding         project/branches
Adding         project/tags
Committed revision 1.
test/tmc$ ls
project  tmcrepository
test/tmc$ svn checkout file:///home/pbg/websites/test/tmc/tmcrepository/trunk .
A    html
A    html/tiny
test/tmc$
/test/tmc/html$ svn propset svn:externals 'tinymce https://tinymce.svn.sourceforge.net/svnroot/tinymce/tinymce/trunk' .
/test/tmc/html$    svn commit -m "propset"
/test/tmc/html$    svn up
/test/tmc/html$

So that is how its done from bash with a vanilla website and one repository checked in for your pleasure. Tips to know include wrapping the directory and resource in quotes, don’t create the directory, specify it in propset and let svn create it for you. Go to a directory somewhere else on your system and test your checkout. In the example above the remote repository trunk is checked out. However, you are also able to check out specific branches or even specific revisions if you want the bias more to stability over new features. You can also specify multiple remote repositories by creating a text file with directory and remote resource pairs and point svn propset at that file. Be prepared to handle things that you flub up using svn propedit. Your repository is not broken, but you may have to know how to fix a thing or two that you didn’t do the first time. That is why doing a vanilla procedure like what is described above helps show what the right way is.

So Imagine having a repository somewhere with all the tools you like to work with as part of your own best practices, sitting there, in one place ready to go with one checkout. That whole kit and kaboodle becomes your blank slate from where to start from, but you are already miles ahead of the competition because you already have tabs on all the resources you are going to use in your project. Having it all on hand saves labor and helps foster better practices as a developer.

  • Zend Framework, CakePHP, Symphony, PEAR or whatever middleware turns your crank
  • PHP Unit, or SimpleUnit, or some other unit testing suite
  • WordPress, Drupal, Joomla, or of course any of the related themes and plugins
  • Tiny MCE
  • Jquery, Scriptaculous, Dojo, whatever floats your boat with javascript
  • XDebug,
  • phpmyadmin
  • Integration testing software like Selenium or Molybdenum
  • bloody well anything from sourceForge, or anything else for that matter public and under svn control.

Links for this blog post:

http://www.superwebdeveloper.com/2008/10/08/essential-cheat-sheet-of-shell-commands/

http://devzone.zend.com/article/9930-The-ZendCon-Sessions-Episode-26-Best-Practices-of-PHP-Development

http://beerpla.net/2009/06/20/how-to-properly-set-svn-svnexternals-property-in-svn-command-line/

http://blogs.gnome.org/johannes/2008/02/20/svnexternals-for-noobs/

Brickskellar Night Out At Codeworks DC 2009

We took a break after day one of the Codeworks DC conference and went to the Brickskellar. The Brickskellar is a famous institution of beer in Washington DC, noted in the Guinness Book of World Records as been the place selling the greatest number of different beers of any drinking establishment on the planet earth. We met up with the group going there in the hotel lobby. We had originally scouted out the fine dining in Alexandria, of which there is plenty. We were thinking of Overwood, 219, The Flying Fish, or others, but on a whim we decided rather to join the conference folks down at The Brickskellar. We got the address from the hotel, entered it in the TomTom, and made it there before the main group did.

We had thousands of possible beers to choose from, but we were most attracted to the pumpkin beers from local microbreweries from the taps. We enjoyed a down home meal of mussels, beef, and a crab cake sandwich and fries. A few things to point out in the pics above: Not the skull foam in the beer glass, the chocolate cake, the double chocolate stout, the elephant tap, the cans in the wall, some familiar faces from the php community, and the trappist ale. So never mind the fine dining in DC, go for the soul food and beer.

CodeWorks in DC October 2009

I am back recently from Codeworks 2009 in Washington, DC. It was in Alexandria, Virginia actually, but close enough, its a big place and its the same thing. This is the first time I have been able to go to a conference  without being involved at all in its planning and organization. I know from experience that a lot of work is put into organizing and hosting a two day event with top-level speakers from all over. The DC Codeworks event was just one event in a series of dates in major cities across the us. Yep, php has gone rockstar. I am proud of the work I have done in the past but I found that by the time the conference came around I was too tired to absorb the lessons as I would like to. So while I am busy recompiling notes from the talks I attended, here are some photos from the conference I would like to share.

The conference was great, I learned stuff, I learned what I know, what I dont know, what I need to know, and more. I met a great group of people and traded lots of business cards.