[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Ruminations on Arch Desiderata

From: Paul Snively
Subject: Re: [Gnu-arch-users] Ruminations on Arch Desiderata
Date: Tue, 16 Sep 2003 20:28:34 -0700

Hash: SHA1

Hello, Tom!

On Tuesday, September 16, 2003, at 01:05  PM, Tom Lord wrote:

Do I understand correctly that you want arch, when it calls `open' on
a file with resource forks, to see when reading that stream a
mime-encoded version of the file plus its forks?

If that is so, what do you expect `diff' and `patch' to do with these?
Or `tar'?   There are at least two issues:

1) diff, patch, and tar are invoked as subprocesses.   At the very
   least, they would have to be modified as well.

2) Let's suppose that I have three streams which are these
   mime-encoded multi-fork files: A B and C.

   Let's suppose that `diff' and `patch' operate on these streams.
   I create a stream D as follows:

   % diff A B > ,tmp

   % patch -o D C ,tmp

   You certainly don't expect D to be a valid and useful mime-encoding
of the patched multi-fork file, at least in the general case, do you?

Good points. My understanding was that arch would not attempt to diff/patch a binary file. I don't see the issue with tar; people tar up AppleSingle files all the time. Once again, MacCVSPro and CVL do exactly--EXACTLY--what I'm proposing for arch. These are front ends to unmodified CVS servers. They've been in use for many years. They work. Any information about why they work with CVS but raise issues with arch is welcome. So now my question is: is my understanding of arch's handling of binary files wrong? That is, are binary files diffed/patched? Merged? Isn't this generally a problem with binary files, with arch or with CVS or with...?

On the DNS-SD support: I think the issue is that you are presuming a
solution where no widely agreed upon problem actually exists.  You
gave one use-case on the help list that was interesting in the
abstract -- but I suspect that if a group of people wanted to solve
the abstract problem, their solution would be rather different than
what you are proposing.

Fair enough. I'd be interested in alternative suggestions, most definitely.

The use case involved people arriving at a conference which hosted a
wireless lan and wanting to "hook in" quickly and easily to all of the
arch archives on that lan.  I would expect a pragmatic solution to
such a problem would involve something like a 5 line shell script, a
README file, a white-board near the registration desk, and a public
FTP site on the lan at a well-known address (well-known via the
whiteboard, of course).   Perhaps there would be a wiki.

Never understimate the power of a dry-erase marker.

I find it impossible to take this seriously. Perhaps you'd care to try again, this time offering an alternative automated solution? Using a computer? Let me point out again that there's at least one CVS server implementation that registers itself with DNS-SD, and at least one CVS client that looks up repositories with DNS-SD. Perhaps I was mistaken in believing that a "global distributed namespace" and DNS-SD were an obvious match; perhaps there's another technology that's preferable. Saying "let's not use technology to solve this problem," however, is a non-starter.

"Fast forward a couple of years. Now the truly massive profit margins
meant that just about any mistake and I mean any mistake, was completely
 masked by the awesome cash flow. Management succumbed to the cash flow
drug and vainly assumed that it was their hard work, superior strategies and dizzying business acumen that was driving the company ever skyward.
 They thought they could do no wrong but they were.

 They thought that t-shirts, purple furniture, jackets, unique building
 architecture, polo shirts, sabbaticals, watches and great product code
 names were the secret recipe for success." --Chad Carlin

----- are+efforts+by+tom+lord&no_note=1&tax=0&currency_code=USD


address@hidden for payments.

Best regards,

Version: GnuPG v1.2.3 (Darwin)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]