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 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.
I know, not
optimal, but FWIW, I wouldn't mind it if someone hacked in a method to
pull down the tree via other means (such as say mercurial, or
subversion) so you could have a local cvs->other scm bridge and worked
on the local scm.
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
right places *by hand* and *when needed*. This way you can have a local
copy of the code, an official tree in the pfsense CVS and also a local
CVS tree with your modifications.
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.
Am I missing something?
Paul
