Re: Getting a move on for 8.2 beta
От | Alvaro Herrera |
---|---|
Тема | Re: Getting a move on for 8.2 beta |
Дата | |
Msg-id | 20060913135049.GA19301@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Getting a move on for 8.2 beta (Tom Dunstan <pgsql@tomd.cc>) |
Ответы |
Re: Getting a move on for 8.2 beta
|
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: