Tom Dunstan wrote: > Alvaro Herrera wrote: > >>I submitted a patch to Andrew, but it needed a couple of tweaks > >>(disabling patching on vpath builds, for example) and I don't think I > >>ever got around to resubmitting it, but if there's more general interest > >>I'll do so. > > > >Huh, why would you disable patching on vpath builds? > > As I understand it, vpath builds only do a checkout to a single place, > and then build against that (from a different directory). Non-vpath > builds take a copy of the checked out source and build in the copy. If > we patched the source in vpath builds, the patch would stick around when > updating the source tree from CVS, and the next patch attempt would fail > etc. Non-vpath builds will get a clean copy to patch in subsequent runs. > I suppose I could have made vpath builds take a copy when doing a patch, > but it hardly seemed worth it.
Huh, but the patch can be applied with -R to revert it after the buildfarm run ... the one problem I can see is if the patch fails for some reason; for which I'd suggest running a patch --dry-run as a first step, checking that it applies cleanly, and only continue in that case. [nice ideas snipped (not sniped)] > Note that the existing patch queue mechanism wouldn't suffice, since > there's no standard way to pull patches through via http or whatever. > We'd probably want to back it with a small database and webapp, which > might just be a hacked buildfarm server. Oh, sure. I'd say there is no "existing patch queue", just a Mhonarc archive which is just useful as a reminder of what patches are there outstanding. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
