Benjamin Reed said:
: Daniel Macks wrote:
:
: > Patch-tracker #768801.
:
: Normally when I'm porting something, I'll put together a basic info
: file, go to another window, build it, and wait for it to die. I go in,
: make some changes, and generate a patch:
:
: diff -uNr foo-pristine foo > /path/too/foo.patch
:
: Then I build again, and start over. If there's something wrong, I run
: the diff again.
:
: If patches are embedded in the info file, every time I want to generate
: a patch I need to delete the patch at the end of the info, close the
: info file, generate the patch, and then re-edit the info file to make
: other changes.
No reason you can't still do this, and treat the embedding as a last-
minute detail after the whole package is working and ready to go. Then
just change %a to %A and stuff the .patch onto the end of .info. I agree
that it makes generating the *next* revision an extra step or two
(re-change %A->%a, rip off the old patch) unless you remembered to keep
the parent file.
: Not only that, but now we're relying on patch not accidentally thinking
: anything in the info file is a directive to start a patch (I don't know
: if it's been done, but I can imagine bits of diff being part of a
: "DescPort" comment or something similar).
My previous approach was to have the new percent-expand yield a shell
command that would give the patch data on STDOUT, so then one could
PatchScript: %[newthing] | patch -p1
and let fink snip off all of the .info before the stop-codon. But I didn't
like having a weird new percent type (command vs. string) and in
particular it would be less of a drop-in replacement for a .patch file.
dan
--
Daniel Macks
dmacks@xxxxxxxxxxxx
http://www.netspace.org/~dmacks
-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1
|
