Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> writes: > > Tom Lane wrote: > >> So? Supplying the derived files via CVS rather than via snapshots > >> won't improve matters at all for people who haven't got the tools. > > > Why do you need the tools if CVS has the files? > > Why do you need the tools if the nightly snapshots have the files? > Same either way AFAICS. > > My objection is basically that CVS is a hugely inefficient mechanism > for delivering derived files. The cost is about the same from a > downloader's point of view as snapshot tarballs --- but we pay for each > update *forever* in CVS storage. I do not mind having CVS permanently > record every feature addition or bug fix; that's potentially-useful > history. But there is zero historical content in derived files.
Oh, that's true. Maybe I should just push the snapshots because those are easier, and cvs isn't even in MinGW. I mount a Unix directory for builds, so I have CVS and all the other tools. Once nice thing about CVS is that you don't have to download the whole tarball each time --- good for code in development like MinGW. Also, one thing I am doing is pushing HEAD changes down in to the branch so I get the HEAD Win32 fixes that go in, and merging will be easier. Isn't that going to make overhead too? > > I added something to configure so the derived files are newer than the > > others. > > Doesn't that break the scenario you were just citing where a WIN32_DEV > user is trying to fix something in a .y or .l file? Sure. I don't anticipate any changes made there. All the stuff left is backend startup stuff. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
