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 *** [EMAIL PROTECTED] *** _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs