There are some good arguments against doing this, but I'll cover those another time.
But anyway, using svn:externals to include external libraries is a convenient way of moving third party libraries out of your own repository.
For example, many PHP applications today, have the Zend Framework as a dependency. To include the library within your application without actually having to download the tarball and use something like phing to set it up in place, you can simply do a
svn propedit svn:externals
Then in your editor, add the following line (each externals definition goes on a new line)
Zend http://framework.zend.com/svn/framework/standard/tags/release-1.10.5/
Set this property on your standard application library directory, or somewhere in your include path.
When you run svn update, svn will pull down the Zend library into your defined location.
The Zend Framework, out of the box, comes with some dojo dependencies that are optionally bundled with the framework. You can use the same approach to pull in the dojo deps by setting svn:externals definitions for your javascript include dir and pointing them at http://svn.dojotoolkit.org/src/tags/release-1.4.3/ (or trunk if you're brave).
Again, there are some good arguments for NOT doing this, but for me, the convenience of this approach outweighs those (which I'll cover in more detail later).
So far I've encountered a couple issues, one which truly boggles the mind.
The first one is the one you're most likely to encounter after upgrading
Fatal error: Call to a member function toHtml() on a non-object in <somewhere>/app/code/core/Mage/Core/Model/Layout.php on line 52
The solution is explained here:
http://rackspeed.de/forum/magento-faq-installation-and-updates/fatal-error-call-to-a-member-function-tohtml-on-a-non-object-layout-php-on-line-529-a-547
Basically edit your theme's layout/page.xml and change <block type="core/profiler" output="toHtml"/> to <block type="core/profiler" output="toHtml" name="core_profiler"/>
The next two are frankly amazing in that they ever made it into the release.
See here:
http://www.magentocommerce.com/boards/viewthread/195761/
To quote the finder of these issues 'Yes, preparing a shipment prepares an invoice instead..'
Magento rewrites work behave differently when overriding a helper class compared to overriding a block class.
In short, when overriding a helper, the context element IS case sensitive. With blocks, it is NOT.
In Magento 1.4, the address format used in PDFs has changed. At this point I'm not sure if this is a deliberate or unintended change. It effects addresses such that they are all displayed on a single line. If you prefer the older, multi-line address display you will need override the formatting in your local.xml file, or with a module (don't be tempted to hack the Mage/Customer/etc/config.xml…).
Please note, within a <![CDATA block, spacing *is* important, hence the lack of indenting.
<![CDATA[
{{depend prefix}}{{var prefix}} {{/depend}}{{var firstname}} {{depend middlename}}{{var middlename}} {{/depend}}{{var lastname}}{{depend suffix}} {{var suffix}}{{/depend}}|
{{depend company}}{{var company}}|{{/depend}}
{{var street1}}|
{{depend street2}}{{var street2}}|{{/depend}}
{{depend street3}}{{var street3}}|{{/depend}}
{{depend street4}}{{var street4}}|{{/depend}}
{{depend city}}{{var city}}, {{/depend}} {{var region}} {{depend postcode}}{{var postcode}} {{/depend}}|
{{var country}}|
{{depend telephone}}T: {{var telephone}}{{/depend}}|
{{depend fax}}<br />F: {{var fax}}{{/depend}}|
]]>
The format may be slightly terse but hopefully you can see how it can be applied to create your own desired format.
Magento models have slightly eccentric camelcasing 'conventions'. In short do not camelcase your model names.
With magento models, you may be tempted to use camelcasing for long class names, for example MyPackage_MyModule_Model_ALongNameForAModel. This will not work as you might expect on different (namely case sensitive) environments.
Your Mage::getModel(mymodule/a_long_name_for_a_model) call will translate to the class loader trying to find A/Long/Name/For/A/Model.php.
Conversely trying to address your model Mage::getModel(mymodule/alongnameforamodel) will see the classloader trying to load Alongnameforamodel.php, and not ALongNameForAModel.php.
On Windows this is fine, on case-sensitive e.g., HFS (Mac) or Unix file-system, this will not work.
One of the (many) gotchyas upgrading to Magento 1.4 is an issue with CMS pages that use a custom layout.
In 1.4 the template layout has changed materially. Previously you will have had a frontend/default/default theme, and probably a frontend/default/custom theme.
Now it's frontend/base/default and frontend/custom/default.
This will bite you, because magento stores the path of the custom theme in the database for each cms_page.
So if your old custom theme was default/custom, you will need to update the database to change it to custom/default or set it to null.
You can avoid this by editing your custom pages and manually saving each one, but that's painful.
Instead connect directly to your database and issue the query:
UPDATE cms_page SET custom_theme = 'custom/default' where custom_theme='default/custom';