beehive-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eddie ONeil <>
Subject Re: updating the beehive web site -- a two pronged approach
Date Wed, 08 Jun 2005 21:22:17 GMT

  Comments in line.


On 6/8/05, Steve Hanson <> wrote:
> Hi all:
> Concerns and questions concerning (1):
> A system very similar to proposal (1) was in place for the v1-alpha release.
> One complaint about it at the time was that Javadoc-generated HTML pages were being checked
in to SVN.  I am not sure how the current proposal (1) avoids this drawback.

You're correct -- the Javadoc is checked into SVN, but it's done so in
a location like:


which keeps it entirely out of the beehive/trunk directory.  As I
recall, keeping the Javadoc in trunk/ was the issue as we were always
sync-ing updates.

The difference here is that it's up at the beehive/site/... level
which devs don't usually need to sync.

> One question: Are we going to be checking in different doc sets for each released version
of Beehive, so that the tree would look (something) like?:
> beehive
>   site
>     archives
>       v1
>       v2
>     current
>       v3

In the long run, yes.  This would make it *significantly* easier to
keep the alpha, beta, m1, etc docs on the site and allow them to be
updateable independently.

> Concerns about (2):
> This proposal sounds like it would break Forrest.  Forrest is looking for one directory
that contains the XML source files: I doubt it can handle a disparate set of directories.
 Runnng Forrest mulitple times and slapping the genered HTML together afterwards won't work
either, because Forrest needs to do link checking and build a single TOC.

Actually, I don't think it breaks Forrest if to generate the entire
doc-kit, Forrest runs multiple times.  For example, to update the
documentation for a nightly, we'd do something like this:

- build a nightly distribution from trunk/
- copy the documentation from trunk/build/dist/... up to
- svn commit the site/publish/docs/nightly directory
- svn checkout on the live-site to refresh the web site

Make sense?  If I'm nuts, let me know.  Just trying to lower the bar
for updating the site and for allowing us to keep multiple copies of
the doc on the site at once.

> Craig R. McClanahan: I know that you have talked about these very issues in
you have any insights here?
> -steve h.
> -----Original Message-----
> From: Eddie ONeil []
> Sent: Tuesday, June 07, 2005 8:05 PM
> To: Beehive Developers
> Subject: updating the beehive web site -- a two pronged approach
> 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

View raw message