Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073