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

Alvaro Herrera                      
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

Reply via email to