Computery

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..

Full-screen browser for OSX - PlainView

Submitted by on

Tags: 

Building my presentation for the FL Drupal Camp I was stuck - neither Firefox nor Safari would let me do a full-screen browser display so the audience was going to be stuck seeing my title bar, browser window border, tool bar, etc - not terribly good for a presentation. A bit of searching later I discovered the perfect solution - PlainView. Built on the same WebKit engine that powers Safari (OSX's built-in web browser), it very simply gives you a border-free, toolbar-free browser that can be made to display in the full screen, hiding everything else. It suited my needs perfectly, I'll definitely be using it again and strongly recommend it.

Moving your TimeMachine

Submitted by on

Tags: 

It's bound to happen to everyone, they outgrow their TimeMachine and want a new one, a bigger one, one that will allow them to go further into the past... I'm talking about OSX's built-in backup system here, I don't know what you were thinking..

So ever since starting to use OSX Leopard I've been using TimeMachine to keep a running backup of my laptop for two reasons - I can instantly jump back to an old revision of a file, and it keeps a near-constant mirror of the OS as it is with all of the software & settings intact. My laptop came with a 120gb drive and I've been using a 160gb USB drive for TimeMachine. Obviously enough, when this is my main machine I move a lot of files around - download lots of files (all legit), delete some, move others to a file server, but with TimeMachine keeping a regular hourly backup of all change files it can end up bloating up pretty quickly. Sure enough, within a few short months I'd filled up the drive and for the past three or four months it regularly informs me that it has flushed some older backups in preference to keeping newer data.

It's 2009 and hard drives of all sorts are insanely cheap. Taking advantage of the early sales I snagged a 320gb replacement internal drive for the laptop and a 500gb external drive for TimeMachine. Incidentally, both of the drives were made by Seagate, as all of my drives are, as all of their drives (at least up through their January 2009 new models) come with a five year warranty, so between backups I'm (mostly) guaranteed five years of usable storage.

Moving on.

I personally don't like moving data off a primary drive due to the inherent reliability problems of external storage - if it's important data then it needs to be on an actively used internal drive, not on a DVD or CD sitting on a shelf somewhere for grubby little fingers to play with (or get knocked over), and definitely not on a USB memory key that's going to get put through it's paces in the next laundry cycle. All external storage formats should be used for backups exclusively. End of story.

So, in order to keep my data intact I planned a drive shuffle. First I was going to migrate the TimeMachine backup data to the new external drive, then I was going to swap out the internal drives and follow up with a quick restore off the backup drive to the main OS drive. Simple enough, and something I've done before.

Well the first step, as mentioned, was to migrate the 160gb (actually only 145gb due to drive companies lying about the size of a "gigabyte") to the new 500gb drive so I could retain the last few months of data as an active backup. That seemed simple enough. Because the drive comes pre-formatted for use with Windows (NTFS), I plugged the new drive to my laptop, ran the funky Seagate software installer & allowed it to wipe & repartition my drive for OSX. After rebooting (yeah, go figure, silly company) I has a 465gb usable drive. But it didn't have my TimeMachine data.

The official guideline on migrating TimeMachine data is to use DiskUtility to "restore" the data to a new drive - odd terminology, but it kinda makes sense. Well, for some odd reason it started giving me an error when I tried this. Just to be sure (and because computers make us crazy by expecting different outcomes for repeating the same procedures) I tried again, and sure enough, the same error.

Poop.

A quick google later and I find two shareware utilities that might also do the trick - CarbonCopyCloner and the amusingly titled SuperDuper. Long story short - both tools would run for a few minutes and then seem to get stuck, sitting with zero change in progress while saying they're copying this file that's actually rather tiny (so it wasn't that it was just moving a huge file). Enough of that, back to google.

A bit more research turned up an article on the excellent MacOSXHints.com which detailed how to use the UNIX tool dd to copy a drive, including to use it to recover lost data off a partition. So I gave it a spin.

The instructions are simple. First off, use the tool "df" to find out the exact location of the partitions or drives you wish to copy (the first column marked "Filesystem"), e.g. the 160gb drive showed as "/dev/disk3" and its partition as "/dev/disk3s2", while the 500gb drive was "/dev/disk2". Then, once you know the drives you just run the following command: "dd olddrive newdrive" e.g. "dd /dev/disk3 /dev/disk2".

Well, while I was overjoyed that my first h@rDk0r3 use of UNIX in some time actually started to do something, I was dismayed to see it say the average copy speed was "1705KB" i.e. 1.7meg per second, and at that rate would take 26 hours to complete. Bummer. As it turns out, by default it works with tiny 512byte data blocks, which obviously takes FOREVER.

While researching it I come across another tool that bids itself as a simpler tool for migrating partitions called "ddrescue". I do a quick download, compile and run, and sure enough it's using the same block size. Sure enough, there's a handy little option called "--block-size", or just "-b" for short, that lets you tell it to use larger blocks of data at a time. A quick "-b 4096" later and the transfer speed jumped to ~5KB. Good enough, though it still took six hours.

After the six hours I now had a drive that seemed to all be there, but it only said it was 145gb and my efforts to resize it with Disk Utility just gave a wonderfully error that says "Error with partition: MediaKit reports partition (map) too small".

Back to the drawing board.

I then thought "maybe I have to copy just the partition instead of the entire drive. Six hours later... and I was left with basically the same thing - Disk Utility said that the entire drive was in one large 465gb partition, but Finder said it was only 145gb.

Back to the drawing board. Again.

And back to Disk Utility.

This time around I deleted the existing partition first so that the 500gb drive was completely blank. I then set the Rescue action to erase the destination. Four hours later it had copied all of the data, another two hours later and it had verified the data.

Golden. Or so I thought.

I now have a single, 465gb partition that shows up in Finder and Disk Utility. The only problem is that Disk Utility says that the drive itself has no partitions! While I'm stumped, I think I'm going to count my blessings, just deal with it - TimeMachine works again, and if I find a fix I'll post an update.

Come to DrupalCamp Florida on Feb 7th, 2009

Submitted by on

Tags: 

Anyone who has February 7th (2009) available, and who isn't already going to the excellent Acts_as_Conference, should take a trip to Altamonte Springs for DrupalCamp Florida! This new event promises a day's worth of free presentations on all things Drupal from some of Florida's best consultants and advanced users, including the exceedingly talented Ryan Price. I've proposed a few talks myself, and the unconference-style of the weekend will mean almost anyone with a bit of experience should feel comfortable taking a few minutes to share something with the rest of the group. At the time of writing there are about 50 people signed up, so there's plenty more space available. I strongly recommend anyone interested in content management, or even just PHP, take at least some time out of their day on the 7th to come along for a look-see.

In addition to the presentations on the 7th there's an effort to have a workshop / group help-like setup for the 8th, and hopefully we'll get to put some of our skills to good use helping others and learning more.

Be there!

Building a Drupal site - pick a theme

Submitted by on

Tags: 

When building a new site in Drupal, unless you've got a large team of developers, one of the first things you're going to want to do is pick a new theme, i.e. a site template. Thanks to the efforts of hundreds of developers from around the world, there are over 170 themes for you to investigate for Drupal 6 (even more if you're stuck with Drupal 5), each one with its own set of traits. For example some use a table-based layout while others use a pure CSS layout, some are single-column designs though most are multi-column, some that have literally tons of slots for you to add content blocks, some with multiple color options, and some that act as just a bare starting point for you to build your own.

Here are a few things to look for when choosing a theme:

Tableless Design

When you design a page layout you have two options for positioning the various components - tables or CSS. Tables are the old way of doing the design and are very inflexible, not to mention difficult to manage, so CSS has become the defacto standard since the millennium.

An important benefit of a CSS design is that you can add an alternative CSS file to make your page instantly printable. It's both horrible from a user friendliness standpoint to require people click to a separate page for it to be printable, but I honestly also find it really dumb to require people do some special trick just to print your content rather than just clicking the browser's Print button. It also gives you, as the site developer (or the person hiring the developer) a much easier time to make global changes, e.g. if you want to make your site all green & red for the holidays or if maybe you decide to tweak the layout a small bit every few months to add some variety, it'll be much easier when there's one master CSS file.

While some of the table-based themes might look good, long-term you and your site will be better off with a CSS-based theme.

Multiple Collapsible Block Regions

Drupal allows you to place portions of content / functionality around your page using things it calls "blocks". Many plugins also can add even more blocks available for you to use, e.g. Tagadelic adds a block showing a tag cloud for your site's keywords, and as a developer you can really easily create your own. Blocks are positioned on your site into spaces called "regions", with most themes having a few standard regions - heading, left sidebar, top sidebar and footer.

While some have taken this flexibility and have gone completely nuts, e.g. AD Blueprint which as 44 regions, I tend to look for one with about eight regions - the usual header, footer and two sidebars, then also one above and below the page content body, plus maybe an additional one between the header and body for e.g. highlighting the week's most important content

Valid Code

In today's technologically competent world there's no excuse for sites to not be present valid code. Using the World Wide Web Consortium's HTML validator and CSS validator, every developer needs to ensure their code is tested and compliant with XHTML 1.0 Transitional ("Strict" is better) and has valid CSS code. Further, themes need to be tested to ensure approximately 99% browser compatibility, which means IE6 & IE7, Firefox and Safari 3. Thankfully most theme developers have done their best to stick with this, so your visitors should have a pleasant experience.

Hopefully the above will help you on your way to build the site of your dreams, with the CMS of your dreams :)

Pages

Subscribe to Computery