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.
