On Thu, Jan 17, 2002 at 03:20:46PM -0800, Tom Lord wrote:
>
> Not if you want the recipient to read it before applying.
>
> I very much want that -- which is part of the reason I like the arch
> patch set format: because it is trivially machine readable, tools for
> patch reviewers can generate conveniently formatted reports that
> explain what each patch set does. Follow the "change history" links
> at www.regexps.com for some examples.
I think you seriously underestimate the number of people out there who
will refuse to even *look* at a patch unless it shows up in trivially
HUMAN readable form in their mail.
> Embedding and compiling a program at patch-application time is
> out of the question.
>
> Sure. But if you are going to make a shell script for exact patching,
> you only need one such script and it can be completely generic.
> There's no reason to fold the script together with each patch set.
I'm not going to make a shell script. I don't consider shell scripts
to be the right solution for anything, except *maybe* interchange of
data with systems which cannot be assumed to have any special software
installed.
If what you're saying is that as long as I'm going to write a custom
parser, I might as well insist that the parsing software be present in
order to do anything with the patch (just like you have to have
patch(1) to do anything with a diff), then I might agree with that.
On the other hand, consider how reluctant people are to install GNU
diff and patch over what ships with the system, even when the system
utilities have serious bugs.
zw
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:57 2006