On 2/28/07, Paul <[EMAIL PROTECTED]> wrote:
Bill Marquette wrote:
> Comment out the call to update_cvs_depot?  Or update that routine to
> better handle a development model that has no CVS access?
Modifying the function to handle SKIP_CHECKOUT (which is documented in
in the wiki) is trivial, as is more trivial to comment it out all toghether.

<flame>What beats me is that there seems to be a documented method to
skip the checkout process, hence it's clearly not implemented (I
wonder...).
You can imagine my surprise when a few hours of work were wiped away
because the build scripts just delete the pfsense source directory and
then proceed to checkout the CVS version. This and other things I
encountered in the build scripts certainly raise the bar for starting
development.</flame>

I'm sure.

I will be very happy to provide a patch for builder_common.sh but I'm
not sure if I should just post it or submit it by other means. I am sure
Scott and other developers have fixed this in their local scripts, and
perhaps forgot to put it in CVS.

Not really - most of us modify stuff on our test systems, if it works,
we commit it.  Any builds done locally end up using the remote
repository.

The point is that CVS can already handle a local/remote repository (as
can mercurial, subversion etc).... All you need is to point it to the

You can't sync two cvs tree's without using vendor branches which is
ugly and painful.

a "cvsupdate_current.sh" would be expected to do this: update the cvs to
the version specified in the tags of pfsense_local.sh
a "build_iso.sh" should just do that... build.

I thought the build scripts did just that, but I never really paid
close attention as I've only ever needed to build something that I've
had in CVS already.

--Bill

Reply via email to