From owner-ctm-announce Mon Jun 12 00:26:41 1995 Return-Path: ctm-announce-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id AAA13841 for ctm-announce-outgoing; Mon, 12 Jun 1995 00:26:41 -0700 Received: from ref.tfs.com (ref.tfs.com [140.145.254.251]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id AAA13835 for ; Mon, 12 Jun 1995 00:26:39 -0700 Received: (from phk@localhost) by ref.tfs.com (8.6.8/8.6.6) id AAA21281 for ctm-announce@freebsd.org; Mon, 12 Jun 1995 00:26:38 -0700 From: Poul-Henning Kamp Message-Id: <199506120726.AAA21281@ref.tfs.com> Subject: what's up To: ctm-announce@freebsd.org Date: Mon, 12 Jun 1995 00:26:38 -0700 (PDT) Content-Type: text Content-Length: 2421 Sender: ctm-announce-owner@freebsd.org Precedence: bulk Hi CTM'ers Here's a little update. I'm currently working on a new mkctm.c and part of that project is to get something better than "diff -n" as edit-generator. Technical details at the end of this message. This will mean that I must update the ctm program to understand the new edit's and give you a fair warning to get your machines updated, with the new ctm before I start to send the new format edits, so now you know. I will send an email when that happens. Next: I'm going to make a couple of "custom" CTM-deltas relative to the 2.0.5 CDROM as soon as I get one. Finally: Several people have expressed interest in improving ctm's client side and I hope to see some results of this soon, in the meantime you can send your ideas to ctm@freebsd.org and they will get to the right people. Now the bad news: I'm going back to Denmark and I may not have too much time to burn the next month and a half, and I may not be able to all of the above before I go. Will keep you all posted. Poul-Henning The new edit format: This is a "string reference" model, which means that it works by pointing to strings in the old file, inserting new strings if needed, to generate the new file. The format is very compact and unreadable to the human eye, but seems to be able to beat the diff -n on all conceiveable distances, and with quite a fair margin on most of them. It is more expensive to find this kind of edit-string than to do an diff, but it has several advantages from a CTM point of view: First: It works on binary files, the special casing of files which had killer-characters in them is no longer needed. Second: It works in memory, I save the fork/exec(diff) part. This actually eliminates the window from I make the MD5 till the diff is run, where a file-modification could sneak in, and make a mess of the situation (This has only happened once, and my check found it, but it is a stupid detail I'd like to get fixed.). Third: The algorithm can be made to stop if the output would become bigger than the entire contents of the file, where a CTMFS is more efficient. Four: Error checking can be made much more water proof. -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Just that: dried leaves in boiling water ?