Re: CVS export

[Jesus Manuel NAVARRO LOPEZ]

Hi, Greg:

"Greg A. Woods" wrote:
> 
> [ On Thursday, October 18, 2001 at 11:49:52 (-0700), John Minnihan wrote: ]
> > Subject: Re: CVS export
> >
> > building =//= releasing, especially when the build is already understood
> > to be an 'overnite' which is at the very bottom of the food chain.
> 
> Of course not -- _BUT_ that's why I qualified my comments with questions
> about why/why/how the nightly builds were to be used.
> 
> If they're actually used to obtain snapshots from which further testing
> and perhaps even decisions about release milestones are made, then
> having tags and using "cvs export" will be the better way to go.
> 

Hmm... but he was talking about nigthly automated builds. I agree with
some other poster this is low on the food-chain.  I *think* that the
advantages of having for these builds an environment simmilar to the one
*should* be on the programer box (hey, so you upgraded gcc without
noticing, ah?) and easing both the "update" (update in general sense,
not the CVS one) of the sources (an export will involve taken afresh
*all* files, not only those that have been upgraded) and make process
(I'm not sure but most probably export will timestamp exported files as
"now" not last modify time on the repo, so you won't have incremental
builds) will superseed those from having a clean source as the one you
will have/need for "production" releases.

> Also, if your nightly builds are used to test your build and release
> process itself then "cvs export" is just as necessary then as it will be
> when you make the actual release.
> 

Well, yes, it is that I don't think daily builds are the best place to
test this.

> 
> On the contrary -- "cvs export" is the best way to guarantee that a
> source release is exactly what should be in the release (and of course
> one would want to build it to ensure that it's a viable release).
> 

Of course, but usually (AFAIK) daily builds scope is not to test for a
*viable release*, but more simply for "hey folks, at least it compiles:
we're in the rigth path"... unless, of course, we're talking about some
Redmon based shop where the "if it compiles is production quality" motto
rules!!!

Anyway, I'd suggest export for any milestone build (where "milestone"
stands for something somehow stronger that nigthly automated builds).

On the other hand, it raises another point I hadn't thougth about
previously: you need to export whenever you want to be sure that your
build process will be (aka, the source files/build environment will look
exactly like) just the same that on your production release environment,
since you will use export for this.  What if simply you get rid
completely of this stage? Unless you're releasing your source to third
parties (and even then, provided you can "convince" those third parties
they *must* use CVS) why not just using *always* tagged updates even for
the production build environment?  Since you *never* will export,
differences between update and export just don't matter.
-- 
SALUD,
Jesús
***
address@hidden
***