On Thu, Jan 17, 2002 at 02:39:26PM -0800, Tom Lord wrote:
> arch's patch format is an entire directory tree (unless I've missed
> something) - this is useless: an extended diff has to be something
> that can be inserted into the body of an e-mail message.
> I agree about e-mail, but not about useless. For example, you can
> send a tree as a uuencoded tar file.
Not if you want the recipient to read it before applying.
> What external commands would that shell script rely on?
mv cp ln rm patch uudecode. I don't believe anything else is
It would be nice to avoid uudecode; both its encoding format and its
command line syntax are disgusting. However, it is universally
available; alternatives are not. Embedding and compiling a program at
patch-application time is out of the question.
> How effectively do you want it to handle inexact patching (e.g.,
> applying it to a tree that has already been rearranged relative to
> the old tree used to generate the patch)?
When run as a shell script, I want it to fail hard if the tree doesn't
match its expectations exactly. Anything more elaborate is left to a
real VC system. That was what the "set -e" at the top of the script
> What protections do you forsee against scripts that contain
> malicious commands?
It's supposed to be simple and readable enough that a user can check
for that before applying - and the generation utility will refuse to
do things that could make the script malicious, e.g. generate absolute
> How will you support tools that automatically manipulate patch sets
> in ways other than applying them (e.g., composing or reversing patch
> sets; generating reports describing patches)?
With a library that parses the patch into a data structure in memory,
and provides helper routines to walk that data structure.
Without support utilities written in C, I do not intend this format to
be useful for anything except applying it to a source tree which
matches the tree it was generated from. This is a basic design-style
difference between me and you; you seem to intend people to knock
together shell scripts which manipulate arch patches, while I wish
to discourage that.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Oct 21 14:36:57 2006