Comments in-line... On 8/17/05, Kenneth Tam <[EMAIL PROTECTED]> wrote: > Right, I don't question that Forrest has real advantages, and for > large amounts of content it's clearly a win -- but the > version-independent site has been hovering around the ~20-25K worth of > content for the past year, with almost all changes being small > incremental diffs (like adding a new committer, adding FAQs, etc).. > this leads me to ask whether the overhead is worth it. I totally see > how Forrest helped with a large change like exiting the Incubator, but > it seems like something on that scale is unlikely to happen to this > content any time soon. > > That said, your point about being able to automate the nightly update > of the current release docs leads me to suggest that we do the same > for the site, which in my mind would smooth the path enough to make > the use of Forrest for all content pretty much pain-free.
Yeah, I definitely understand your point about simplicity, but I also think that you'll find Forrest pretty painless. And, it's just less work for simply maintaining the site (not just the content). > > This makes a lot of sense -- it sounds like Forrest essentially always > does a "clean" build (ie pretty much all files get re-written even if > there are no changes in them). Given that, and the ability to > automate the update process on the server so that the only time you'd > have to login to the server and do the tarball management yourself is > if you couldn't wait for the nightly update, I think life is good. I think it's safer to always do a "clean", and when combined with API Javadoc, it's just easier to always start from scratch (and doesn't take that long). The way this would be automated would be to script the "sftp" upload and then just run cron on the server to crack the nightly tarballs. So, it's something a project committer can do and is just something I need to roll into the nightly process. For the released doc, doing this sftp / ssh a few times a year doesn't seem that bad. :) Eddie But,
