On Fri, Oct 8, 2010 at 03:52, Andrew Dunstan <and...@dunslane.net> wrote: > > > On 10/07/2010 03:37 PM, Magnus Hagander wrote: >> >> On Thu, Oct 7, 2010 at 21:31, Andrew Dunstan<and...@dunslane.net> wrote: >>> >>> On 10/07/2010 10:11 AM, Magnus Hagander wrote: >>>>>< >>>>> OTOH, this patch seems pretty small and simple to maintain. >>>> >>>> True, it is rather small. >>>> >>>> Does anybody know if there's an automated way to maintain that on >>>> freebsd ports, and if so, how that works? I want to be *sure* we can't >>>> accidentally upgrade git-cvsserver *without* the patch, since that is >>>> a security issue. >>>> >>> Why not just make a local copy somewhere else and patch and run that? >>> It's >>> just a Perl script, no? >> >> Yeah, but then we have to remember to manually patch that one when >> somebody *else* finds/fixes a security issue. We have automatic >> monitoring on the ports stuff to detect when that happens.. > > There's a simpler solution which I have just tested. Instead of patching, > use the Pg driver instead of SQLite. Set the dbname to %m. If the database > doesn't exist the cvs checkout will fail. So we just set up databases for > the modules we want to export (master and RELn_m_STABLE for the live > branches).
A database per branch seems like a horrible idea in general, but if it works us around the bug, it seems like a doable idea.. As long as we'll never have a branch called "postgres" or "git" (already in use on that box). I'll look into it. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
