Notes on MPW Projector

This is a collection of notes I've made about MPW projector. While most of them are negative, I'd like to point out that Projector is a good version control system, and I continue to use it. If I didn't use it so heavily, I wouldn't have found these problems. They do point out situations where you might be better with another version control system, though.

For information on other Macintosh version control systems, please see Richard Wesley's Macintosh Version Control for an excellent review.

Projector is a version control system that's part of Apple's Macintosh Programmers Workshop (MPW). It's a filesystem-based, Macintosh-only version control system.

High-latency connections

Projector tends reads database file in small chunks. It starts at the beginning of the file, reads the information it needs to find the data for the next step of the operation, seeks ahead, and then reads the next bit of information.

On large multi-level projects, this can take quite a bit of time. On a 256K DSL connection from Minnesota to California, it takes almost five minutes to simply mount a project containing just under 1900 items in a project with 24 sub-projects. Bandwidth isn't the bottleneck. Latency is.

Having looked at the packets actually going over the network, the problem is the large number of small packets, many of which need a reply before the next packet can be sent. A simple ping from me to the server in CA takes over 100 mSec in the best of conditions. This is due mostly to the convoluted path it has to trace. This means that every packet that requires a response before the process can move on adds at least 100mSec to the total time. For each of the sub-projects in the projector database, there are over twenty of these packets being exchanged. That means the best I can do is to mount the project in 48 seconds. Since the number of packets is actually higher, and there's some processing time and hard-disk access involved on each end, it's closer to two or three minutes for the best possible time to mount the project.

During peak times of the day, a simple ping can take over 300mSec, due to increased network congestion. I don't even try to use the remote server during these conditions.

Is there a solution to the latency problem? Not using a filesystem-based version control system like Projector. The client workstation has to do all the thinking, so it needs to access much of the file. Using a client-server version control system can offer much better performance, since the client simply says "Give me version X of file Y" and the server does all the file accesses locally. CVS and Perforce are two such systems.

Database corruption

The way Projector databases get corrupted is typically when the connection to the fileserver is lost in the middle of an operation. Your local workstation has started writing the database file with updated information, and in the middle of the write, the connection is dropped.

There are two solutions to this. The first is to make sure the network doesn't go down. That may or may not be in your control. The second is to back up the database frequently. You may still corrupt it, but at least you'll be able to go back to a good version. The only problem with frequent backups is that ocassionally you'll have a database get corrupted and nobody will notice. I recommend writing a script to check all of your projector databases on regular basis.

Polaschek Computing, Inc. Welcome to Polaschek Computing, Inc.

Home Products Consulting On Printing Manila Bits Feedback Dave Getting Started Miscellany				Notes on MPW Projector This is a collection of notes I've made about MPW projector. While most of them are negative, I'd like to point out that Projector is a good version control system, and I continue to use it. If I didn't use it so heavily, I wouldn't have found these problems. They do point out situations where you might be better with another version control system, though. For information on other Macintosh version control systems, please see Richard Wesley's Macintosh Version Control for an excellent review. Projector is a version control system that's part of Apple's Macintosh Programmers Workshop (MPW). It's a filesystem-based, Macintosh-only version control system. High-latency connections One problem with MPW appears on high-latency connections. For more information on latency versus bandwidth, please see It's the Latency, Stupid (Part 1) and Part 2. Projector tends reads database file in small chunks. It starts at the beginning of the file, reads the information it needs to find the data for the next step of the operation, seeks ahead, and then reads the next bit of information. On large multi-level projects, this can take quite a bit of time. On a 256K DSL connection from Minnesota to California, it takes almost five minutes to simply mount a project containing just under 1900 items in a project with 24 sub-projects. Bandwidth isn't the bottleneck. Latency is. Having looked at the packets actually going over the network, the problem is the large number of small packets, many of which need a reply before the next packet can be sent. A simple ping from me to the server in CA takes over 100 mSec in the best of conditions. This is due mostly to the convoluted path it has to trace. This means that every packet that requires a response before the process can move on adds at least 100mSec to the total time. For each of the sub-projects in the projector database, there are over twenty of these packets being exchanged. That means the best I can do is to mount the project in 48 seconds. Since the number of packets is actually higher, and there's some processing time and hard-disk access involved on each end, it's closer to two or three minutes for the best possible time to mount the project. During peak times of the day, a simple ping can take over 300mSec, due to increased network congestion. I don't even try to use the remote server during these conditions. Is there a solution to the latency problem? Not using a filesystem-based version control system like Projector. The client workstation has to do all the thinking, so it needs to access much of the file. Using a client-server version control system can offer much better performance, since the client simply says "Give me version X of file Y" and the server does all the file accesses locally. CVS and Perforce are two such systems. Database corruption While it's fairly rare anymore, I've also had experience with database corruption in Projector. This was back before Apple had opened up the file format, so there was no hope at all of recovering the lost data. It was simply gone. The way Projector databases get corrupted is typically when the connection to the fileserver is lost in the middle of an operation. Your local workstation has started writing the database file with updated information, and in the middle of the write, the connection is dropped. There are two solutions to this. The first is to make sure the network doesn't go down. That may or may not be in your control. The second is to back up the database frequently. You may still corrupt it, but at least you'll be able to go back to a good version. The only problem with frequent backups is that ocassionally you'll have a database get corrupted and nobody will notice. I recommend writing a script to check all of your projector databases on regular basis.
Last update: Thursday, April 6, 2000 at 11:05:01 AM by Dave Polaschek.

Polaschek Computing, Inc.