Re: pgsql-server/src backend/bootstrap/Tag: backen ...

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