updating the beehive web site -- a two pronged approach

[Eddie ONeil <ek...@gmail.com>]

All--

  After having worked on the Beehive website some in the last couple
of days, I've got a couple of suggestions for how we can make this
process significantly easier.  The approach has two parts...  The
first is the most (immediately) important.

1) check the generated website into beehive/site in a read-only part
of SVN.  This would allow committers to generate the website, check it
into SVN, and then check it out on the server.  This process avoids
the generation and "scp" of a .zip file to the server and then the
"ssh" to crack the .zip file.  To update the site, just run "svn
update" on the live site.  This also makes it easier to roll back
after a failed change.

2) the next step would be to decouple the release-independent content
of the site from the release-dependent documentation.  This would move
things like the links to the mailinglists, downloads page, news page,
etc out of trunk/ and up a level so that it's versioned independently
of the versions of Beehive.  This is checked into something like:

beehive/
  site/
    author/ -- location for the content in the tree
    publish/ -- location of the generated site

Then, the release documentation can be generated, copied up to
publish/, checked into the tree, and "svn update"ed on the live site.

Step (1) is something we can do now and would make updating the site
quite easy.  Step (2) is something we can do longer term but would
decouple the release documentation from the more static website.

  Thoughts?

Eddie

Re: updating the beehive web site -- a two pronged approach

[Richard Feit <ri...@bea.com>]

+1 to both -- I totally agree with this.

Rich

Eddie ONeil wrote:

>All--
>
>  After having worked on the Beehive website some in the last couple
>of days, I've got a couple of suggestions for how we can make this
>process significantly easier.  The approach has two parts...  The
>first is the most (immediately) important.
>
>1) check the generated website into beehive/site in a read-only part
>of SVN.  This would allow committers to generate the website, check it
>into SVN, and then check it out on the server.  This process avoids
>the generation and "scp" of a .zip file to the server and then the
>"ssh" to crack the .zip file.  To update the site, just run "svn
>update" on the live site.  This also makes it easier to roll back
>after a failed change.
>
>2) the next step would be to decouple the release-independent content
>of the site from the release-dependent documentation.  This would move
>things like the links to the mailinglists, downloads page, news page,
>etc out of trunk/ and up a level so that it's versioned independently
>of the versions of Beehive.  This is checked into something like:
>
>beehive/
>  site/
>    author/ -- location for the content in the tree
>    publish/ -- location of the generated site
>
>Then, the release documentation can be generated, copied up to
>publish/, checked into the tree, and "svn update"ed on the live site.
>
>Step (1) is something we can do now and would make updating the site
>quite easy.  Step (2) is something we can do longer term but would
>decouple the release documentation from the more static website.
>
>  Thoughts?
>
>Eddie
>
>  
>