WordPress 2.0.3 was released today, so I had a chance to try out the vendor drop technique in Subversion… and it worked well!
The idea is to maintain a branch in the repository that mirrors the releases of the vendor. Mine now has this directory structure:
vendor/wordpress/latest/ vendor/wordpress/2.0.2/ vendor/wordpress/2.0.3/Where the numbered directories are tags (snapshots) of the latest versions of WordPress at different points in time. The copy with my revisions – the code that powers this site – is in trunk/wp/.
Once the vendor branch was up to date, I just merged the changes made between 2.0.2 and 2.0.3 into the trunk. The changes touched many files, but since this was a point release, most of those changes were minor. In fact, only one line of code conflicted, and that was just a simple syntax issue. After fixing the conflict and briefly testing it, I uploaded the changes to the server, and now I'm running Wordpress 2.0.3.
Of course, a more substantial release (2.1 or 3.0, for example) would cause more problems. Probably some of my hacks will have to be rewritten. But still, the version control is an indispensible safety net. I won't have to remember everywhere that I made revisions.
I had been programming for more than 10 years before I learned about version control. (But remember, I started programming when I was 10 years old!) So when I first encountered it, I thought, “where have you been all my life?” And that was just SCCS on Ultrix – pretty primitive compared to what we have now.
Subversion is pretty usable, but my first choice on new projects lately is Darcs. I like its distributed/disconnected nature, and its clean design. But there is some question as to how well patch-oriented (rather than snapshot-oriented) tools handle vendor drops. I'll have to experiment more.
