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://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/
