Loose cables and electronics are bad. In electronics as sophisticated as computers, they can cause really odd behavior!

My wife’s Mac Mini was exhibiting odd behavior, namely, sporadic loss of sound. The internal speaker would suddenly become unavailable to the operating system. Furthermore, the speakers did have a slight hum when they were plugged into the Mac Mini. I had opened the Mac Mini up a couple times to upgrade the RAM, so I figured I must have inadvertently pulled the audio line. A few months later, the Mac Mini just outright refused to start up. I’d push the power button, I could hear it power on, but there was no startup chime and no boot-up. I figured the Mac had finally died, but I naturally wasn’t going to give up on it without an autopsy.

If you’ve ever looked at a tutorial on opening the Mac Mini, you know it isn’t the worst thing ever, but it definitely is more complicated than opening, say, a Mac Pro, or really any tower computer. One of the challenges is separating the top chassis, since it is connected with a few cables. One of these is a ribbon in the back, and this ribbon is what was giving me trouble. Take a look at the photo below.

As you can see, the connector was actually in the open position, so the ribbon was sitting loosely in the connector, sporadically losing its connection and wreaking havoc on the system. The ribbon must have eventually pulled away enough so that the computer couldn’t start up at all.

Here’s the ribbon properly inserted and the connector closed shut:

The Mac started fine after that, and it hasn’t had any startup or sound problems since.

A few months ago, I posted an article about combining multiple Subversion repositories into one large repository. Some folks have expressed an interest in doing the opposite--separating one large repository into multiple smaller repositories. The process is not without its quirks, but it can be done.

At first glance, you'd conclude the process would work much the same way: Loop through the individual directories in the large repository, create smaller repositories for each one, then dump and import the contents of each directory into its small repository.

The tricky part is that the Subversion dump command dumps everything in the repository, by revision. In order to pull just a single directory, you must filter a complete dump with the "svndumpfilter" command. This blog post by AllMyBrain.com basically explains how to accomplish this in Linux. I usually have to work on a Windows box on the job, so I wrote up a script to accomplish this in a Windows batch script.

The strategy is the same as the Linux script, though. We're going to use "svnadmin dump" the large repository, then use "svndumpfilter" to filter by just the directory we want, then "svnadmin load" the results into the newly created repository. All of this can be combined into a single statement via piping:

This will make a little more sense when we look at the full script. Let's just put it out there and then go through it.

First, we're setting our paths. "SmallRepoPath" will be the directory holding all of the small repositories we'll be creating. "PathToRepo" and "UNCToRepo" point to the big repository as DOS and UNC paths, respectively. "PathToChkout" points to a Subversion checkout of the large repository.

First, we check out the large repository with the "svn co" command. We do this just so that we can call the "dir /A:D /B" command, which says, "List just the directories in the checkout directory." We use that output to loop through each directory in the large repository.

Then, for each directory in the large repository, we create a corresponding small repository, then do our dump/filter/load combo. Again, we're dumping the contents of the large repository, using "svndumpfilter" to filter by directory, then loading that filtered dump into the new small repository.

Finally, we just do some cleanup by removing our temp files and the checkout directory.

There are a few caveats with this code.

First, it will import all of the large repository's revisions into the smaller repository. There are svndumpfilter arguments to prevent this, such as --drop-empty-revs and --renumber-revs, but I found the Windows Subversion binaries to be problematic with these arguments. The end result is that you have more revision numbers than needed, but only the relevant data is actually imported into the repository, and viewing logs on just the imported directory will still obviously show revision logs related to that directory, so there's really little harm done.

Second, the dump/filter/load action doesn't always work on a directory that has been moved (copied/deleted) from another location within the large repository. What's worse, it won't fail, it just won't load any data into the small repository. To address this, use the --revision argument on the "svnadmin dump" command to do a dump starting at a revision after the move took place. Doing so will give the "svndumpfilter" command something it can work with.

This process is certainly more complicated to explain, but ultimately there's not that much more going on. Hopefully this explanation is helpful to you.