Farr, Aaron wrote:
1. The generated site contents are in SVN/CVS which means we DO have a revision history of the generated site. We get automatic backups, can revert to an older version, etc.
Apparently I didn't get my main message across. I challenge this assertion, and think it is outright wrong!
2. With the exception of the cron job which does an "svn up", it doesn't require unix shell access for anyone else to update the site. It does require that they have SVN access. The ASF would like to get to a point where there was little to no need for individual unix accounts.
Ok. This is a funny argument, especially after reading 3. below, which basically says "shouldn't have John Doe & Co mucking around with the site". Wouldn't the situation with 'few unix accounts' actually improve the safety-net ?
3. You don't have someone directly mucking around in the public html directory manually making changes which can immediately impact site availability. We'd like to have as few as possible people or scripts directly hit /www/avalon.apache.org
Well, if we are talking about bad intent, there are so much you can do to make it really hard to restore the site. SO, I tried to show what typically would happen during a 'mishap'. Far from easy to recover from it. It sounds easy, but the two major flaws are;
- No feedback to the person actually doing the site update. That leads to 'forgetting to check' or 'sleeping', when the update eventually occurs.
- Reverting to older revision is not just a matter of checking out an older version. The cron job will take the latest version, which means that an older version must be re-committed in the SVN. And the source of the problem should also be fixed (although can possible be deterred, but doesn't make sense to do).
Keeping those in mind, I think it would be great to have a better, faster, smoother solution. It would be nicer to just commit the XML source docs and not have to commit generated HTML, but that also requires the server to run the transformation scripts which are both much more prone to failure and also more CPU intensive than a simple "svn up."
IMHO, the issue is not simple, and on the surface the repository solution sounds more appealing, but I think it is a mirage.
The repository way also introduces a possible descrepancy between the central/site and the actual site, since I can hack stuff into asf/avalon/site directly, which further makes me think it is a bad solution.
Sorry, I can only find negatives with the 'LSD' approach, and I think we should employ a different mechanism.
For instance,
The build system uploads the 'new site' to avalon.apache.org/[revnumber] so that the site can go live 'for a while' first. Then a manual change of a avalon.apache.org/latest to avalon.apache.org/[revnumber] is made by someone with shell account (currently everyone). At the same time, such person can remove 'older' site content from their respective folders.
Cheers Niclas
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
