Subversion

Pressflow-6 and Pantheon-Mercury on GitHub (updated x2)

Submitted by on

Tags: 

In the past year I've discovered two things:

  • The revision management system Bazaar (aka "bzr") is an occasionally flaky little thing and I've experienced several crashes doing mundane tasks. I much prefer using Git or even Subversion as they've proven to be rock solid in my use of them over the years.
  • The Drupal fork Pressflow has a lot going for it.

However, because Pressflow uses Bazaar rather than Git I've been reluctant to bother trying it. Now that I'm working somewhere that is starting to use Pressflow for production sites I figured it was time to get over the headaches and start contributing.

As my first step towards this goal I've set up what I'm intending to be a semi-permanent mirror of Pressflow-6 on GitHub. While there were two existing mirrors neither of them had been updated yet, so now at least there is an up-to-date mirror of it available. In doing this I am committing to keeping this current for as long as I am using Drupal 6 for work, which should continue through 2011 and probably longer.

I'm also going to see if I can get involved a bit more with the Pressflow group, possibly throw some ideas learned during my days at Bonnier to help improve Drupal 6's performance for high-traffic sites, especially for logged-in users.

One of the most common uses of Pressflow is as part of the larger Pantheon Mercury project, which is a custom OS configuration for making installations of Linux tailored specially for running Pressflow, complete with a reverse-proxy engine and a local install of the Solr search engine. At Bluespark Labs we're standardizing on using this as the basis for all new production installations so it's in my best interests to know how it works and, potentially, contribute to the effort. So, like with Pressflow, my first step towards this is to create a GitHub mirror of the Pantheon project, which I'll try to keep current.

Update: You can also access the repository using Subversion, which can be useful to e.g. use svn:externals to save some steps when updating:

  • svn checkout http://svn.github.com/damienmckenna/pressflow-6.git

Update x2: FourKitchens, one of the leaders in the Pressflow group, have announced their own official git and svn mirrors of the bzr repository:

Downgrading svn repositories from 1.5 to 1.4

Submitted by on

Tags: 

It's an odd situation, but occasionally you need to convert your data to run on an older version of an application rather than the typical upgrade to newer versions. One such situation arose for me recently. I was starting a new project and was beginning to add/change code while working from home after-hours, with obviously no server admins around to IM a request for a new subversion repository. Being the agile developer I am, I figured I'd just create a local repository and upload it when I was next at the office.

As you may know, practice rarely follows theory. The theory was that I'd just do an svnadmin dump to create a data dump of my local repository and then svnadmin load to get it onto the main svn server at work. As it turned out, I forgot to check something. You see, the svn server uses v1.4 while I've been running v1.5 for about eight months, since shortly after it was first released - as a result, after several days of development my fresh 1.5 data dump wouldn't work with the server's v1.4. Bummer. I submitted a request for the IT department to upgrade the servers to 1.5 - there are several good reasons to do the upgrade - but it isn't something that's going to happen too quickly due to the need to then have all of the other users upgrade their clients.

Thinking I was going to be stuck for a while keeping my repository locally, I kept working locally and figured I'd be able to just wait the few weeks until the central upgrade. Again, life never works quite like you think it will, and I suddenly immediately needed to be able to upload my work to a staging server. Within an hour of dealing with SFTPing files to the server, trying to ensure two different instances of the servers were kept up-to-date and concurrent, the horrors of Life Before Revision Management came flooding back to me and in a mad panic I set out to get my code into a repository one way or another.

This is where my current web hosting provider, Dreamhost, saved my sanity. I had previously set up a repository on my account for some personal code development so figured I'd repeat my success there with the new project, as it would at least be accessible remotely. A couple of quick minutes had an svn dump of the repository waiting on the server for me to import into a new repository. Except it didn't want to work, it turned out that even Dreamhost was using the older v1.4. Argh! It seemed I was doomed to fail!

It was around now I thought "why don't I RTFM?" A quick look at "svnadmin help dump" didn't turn up anything, ditto for "svnadmin help load". Then I tried "svnadmin help create" and saw the previously unknown (to me) option "--pre-1.5-compatible" which is described as "use format compatible with Subversion versions earlier than 1.5" - a step in the right direction! This option would allow me to create a local repository in my local v1.5 setup which would then be compatible with v1.4. I guessed that it might then also create a dump file compatible with v1.4, which could then be cleanly imported into a new v1.4 repository... and sure enough it worked!

So, the exact steps I took were:

  • Created a dump of the v1.5 repository named myproject_1_5.dump using the command "svnadmin dump myproject > myproject_1_5.dump".
  • Created a new repository that was compatible with v1.4 using the command "svnadmin create --pre-1.5-compatible myproject2".
  • Imported the v1.5 dump file into the new myproject2 with the command "svnadmin load myproject2 < myproject_1_5.dump"
  • Created a dump of the v1.4 repository named myproject_1_4.dump using the command "svnadmin dump > myproject_1_4.dump".
  • Uploaded project_1_4.dump to the hosting account.
  • Created a new repository: svnadmin create myproject
  • Loaded the new data dump: svnadmin load myproject < myproject_1_4.dump".

Then, after a few quick moments (it was only up to rev 103 at this point) I was finally able to get back to development using a centrally accessible repository for a few days until I'm back at the office again and can get it back onto company territory.

NOTE: Yes, I know that git would probably have worked better in this situation, but the company is not currently ready for that move..

One solution for "unexpected T_SR" errors in PHP

Submitted by on

Tags: 

Here's a little tidbit. If you ever get "Parse error: syntax error, unexpected T_SR" errors in PHP, check to see if you had any svn merge conflicts. This error raised its ugle head this evening for me and that's exactly what it turned out to be. Then just bounce over to your svn client of choice, fix the conflict (or just delete the offending files and grab the latest file again), and the error will disappear.

Why Trac sucks

Submitted by on

Tags: 

Reasons to use Trac:

  • It has been around for ages so it's pretty well known.
  • It works with Subversion.
  • Built-in Wiki.
  • The milestones system works fairly well.

Why Trac sucks, IMHO of course:

  • It's written in Python, a language I currently don't know nor have a (current) inclination to learn.
  • It doesn't do git without a plugin.
  • How do I get email notifications when something's changed in the wiki?
  • How do I get email notifications when code changes are uploaded?
  • Each project you want to manage with it gets its own separate install, which is very klunky. You have to log into each one separately (unless you set up a shared authentication system of some sort in the web server).
  • Each project only gets one repository.
  • The interface is klunky, e.g. clicking View Tickets brings you to a page where you first have to choose your filter rather than just loading the last one used or a default.
  • No task associations so you can't do a parent-child dependency to indicate a completion hierarchy.
  • The interface should allow for trag-n-drop changing of priorities.
  • It isn't github or unfuddle or Redmine :)

Personally I recommend github for public projects where you don't need task management (I don't like Lighthouse), Unfuddle for closed projects or where you want good task management for your open project, or Redmine if you want full control and to host it all yourself.

Just thought I'd share that.

git-svn *does* work on Windows!

Submitted by on

Tags: 

Huge thanks to the msysgit team for their hard work, because after some testing I've discovered that their git/git-svn port does work, whereas trying to get it working under Cygwin is a quite broken right now. Got git it!

Note: You need to get the Git-1.5.5-preview20080413.exe release if you want to try git-svn, the Git-1.5.6.1-preview20080701.exe release has a broken git-svn.

Pages

Subscribe to Subversion