PUBLIC MARKS from greut with tag svn

Until recently, Pinax had two choices for a given external dependency:

1. use svn:externals and point to the external dependency's svn repository
2. include the external dependency code in the Pinax codebase

However, there are problems with this approach:

1. it largely relies on external dependencies being in svn and this is increasingly not the case (although it was when Pinax started)
2. it makes it difficult for Pinax itself to move away from svn
3. there is no management of dependencies between external dependencies, nor between particular projects in Pinax and their individual dependencies

To solve these problems and more, Pinax is switching to a distutils-based approach. This means:

1. externals dependencies are encouraged to be released as distutil-compliant packages with a valid setup.py and put on PyPI
2. development versions of dependencies can be pulled in in a variety of different ways including from git, hg or bzr repositories

svn:externals are evil

the evil is SVN itself not handling changing of externals (i.e. to/from an external) in basic operations like updates and merges, which may cause a lot of manual work on your end, and break automated builds or similar.

wondering about massively usage of it.

This article covers how to build a simple ActiveWarehouse data warehouse using the Subversion logs from the Rails project.

Time to forget about data normalization

This is a way of getting the complete history of the file in one textual output. It's great for finding a snippet that you suspect existed somewhere in the file's past.

more tools to be silly