RE: [general] screwed up Commons site
I know for Jelly when I've rebuilt the site, I've never checked it in to CVS. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 03:55:47 PM: It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? As far as I know, they should all be checked into CVS, regardless of whether they are built with anakia, forrest or maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 02:29:18 PM: I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Ditto. But in the case of Latka and HttpClient, I expect anything checked into CVS to be using CVS. Still need to sort them out. The HttpClient cvs diffs could just be something daft like a bad line ending, but if so then it's confusing cvs enough to suggest everything is different. I'll mess around with the -b options to diff etc to see if it's just dos/unix formatting. Hen On Wed, 19 Nov 2003 [EMAIL PROTECTED] wrote: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ Noel J. Bergman [EMAIL PROTECTED] wrote on 18/11/2003 02:29:18 PM: I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
On 18 Nov 2003, at 04:55, Noel J. Bergman wrote: It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? As far as I know, they should all be checked into CVS, regardless of whether they are built with anakia, forrest or maven. Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? -John K - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: [general] screwed up Commons site
Noel wrote: As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. Martin Cooper wrote: This makes a great deal of sense. Unfortunately, as far as I'm aware, none of the Maven generated sites are checked in. That's probably because Maven does so much (e.g. site:deploy) that it doesn't occur to people (including myself) to take the extra step and check in the generated site. I'm not aware of an actual policy that requires this, but it wouldn't be a bad idea. Perhaps I'll bring that up on [EMAIL PROTECTED] In the meantime, it would be a good policy for us to introduce to Commons, at least, while we're in the process of sorting out our own web site infrastructure. Dion Gillard asked: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. It is part of the official documentation maintained in the Apache site module by the infrastructure team: - Every project also has a proj-www module that corresponds to the public website specific to that project. This module appears when one goes to the web site http://proj.apache.org;. ref: http://www.apache.org/dev/svc-name-template.html - All CVS modules are in the form $project[-$codebase], where $codebase is an optional extension for subclassing the project into a couple separate parts. Decide which CVS modules you want to create. There should be at least one for the web site, $project-site. Create /www/$project.apache.org directory, chmod g+w, chgrp'd to $project. Do a cvs checkout $project-site into that directory ref: http://www.apache.org/dev/project-creation.html - The websites are served from directories under /www on daedalus. But you usually do not edit any content in those directories. Each website is an anonymous CVS checkout of a repository on icarus. ref: http://www.apache.org/dev/committers.html#web That last one goes into more detail. Obviously, the documentation needs a bit of tidying, but the concept is still the same. I am cc'ing infrastructure@, so if there is any change from this infrastructure policy, the team can let everyone know. Otherwise, I think that this remains policy. John Keys asked: Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? In the event of some sort of failure, e.g., an accidental deletion or some other problem, the infrastructure team cannot be assumed to have access to the tools, nor knowledge to use them. Plus it would take much longer to restore by re-building than by doing an update from CVS. There is also an oversight issue. If there were some sort of defacement (there was a perceived one last year), it can be checked against CVS records (turned out that it was not a hack, just an ill-advised comment that a Commiter had checked in). And those CVS records can be checked against replicated copies. Those are just a few things that occur to me off-hand. I am sure that those who developed the policy in the first place have even more reasons, and experiences behind them. Mark R. Diggory wrote: I'm of the opinion that a proper backup system is the appropriate solution here, this is not an ideal usage of cvs and is just going to bloat the cvs contents. Those are issues for the infrastructure team, which issued the policy documented above, to deal with. As for the latter, apparently it has not been considered an issue to date. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Still need to sort them out. The HttpClient cvs diffs could just be something daft like a bad line ending, but if so then it's confusing cvs enough to suggest everything is different. I'll mess around with the -b options to diff etc to see if it's just dos/unix formatting. The HttpClient docs in CVS have not been updated for at least a year I believe. We've just been pushing the content using maven site:deploy. If it turns out that we should be using CVS for site documentation I will update CVS, if not I will delete HttpClient from CVS and stick with site:deploy. I'm just waiting for a definitive answer from infrastructure, or whomever else wants to make the official judgment. Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Anyone from Latka got a clue what's screwed up with their docs/CVS? Lots of clashes if I attempt to cvs update those. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
I'm just waiting for a definitive answer from infrastructure, or whomever else wants to make the official judgment. Unless infrastructure replies otherwise to the e-mail I sent this morning, I think you should assume that the currently posted policy stands. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
re: [general] screwed up Commons site
Noel J. Bergman [EMAIL PROTECTED] wrote on 19/11/2003 04:52:48 AM: Noel wrote: As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. Martin Cooper wrote: This makes a great deal of sense. Unfortunately, as far as I'm aware, none of the Maven generated sites are checked in. That's probably because Maven does so much (e.g. site:deploy) that it doesn't occur to people (including myself) to take the extra step and check in the generated site. I'm not aware of an actual policy that requires this, but it wouldn't be a bad idea. Perhaps I'll bring that up on [EMAIL PROTECTED] In the meantime, it would be a good policy for us to introduce to Commons, at least, while we're in the process of sorting out our own web site infrastructure. Dion Gillard asked: Is this a definite rule? Is there somewhere it's mandated? I'm asking as I don't remember it being required. It is part of the official documentation maintained in the Apache site module by the infrastructure team: - Every project also has a proj-www module that corresponds to the public website specific to that project. This module appears when one goes to the web site http://proj.apache.org;. ref: http://www.apache.org/dev/svc-name-template.html Yep, I've seen this before, but it doesn't seem to be used in practice. - All CVS modules are in the form $project[-$codebase], where $codebase is an optional extension for subclassing the project into a couple separate parts. Decide which CVS modules you want to create. There should be at least one for the web site, $project-site. Create /www/$project.apache.org directory, chmod g+w, chgrp'd to $project. Do a cvs checkout $project-site into that directory ref: http://www.apache.org/dev/project-creation.html - The websites are served from directories under /www on daedalus. But you usually do not edit any content in those directories. Each website is an anonymous CVS checkout of a repository on icarus. ref: http://www.apache.org/dev/committers.html#web That last one goes into more detail. Obviously, the documentation needs a bit of tidying, but the concept is still the same. I am cc'ing infrastructure@, so if there is any change from this infrastructure policy, the team can let everyone know. Otherwise, I think that this remains policy. John Keys asked: Is it not enough to have the source of the site in CVS? For example, the xdocs (and associated artifacts) for a maven generated site. Is there an added benefit to having the generated HTML in CVS also? In the event of some sort of failure, e.g., an accidental deletion or some other problem, the infrastructure team cannot be assumed to have access to the tools, nor knowledge to use them. Plus it would take much longer to restore by re-building than by doing an update from CVS. Shouldn't this be covered by some sort of backup, rather than having CVS as the placeholder? Or by zipping the current site and storing it in an archives directory. Since the sites are almost always generated from tools, having the source and the result in CVS seems overkill. If a project site was to be down due to hardware issues, a small wait while the project team brought it back up shouldn't be too bad. There is also an oversight issue. If there were some sort of defacement (there was a perceived one last year), it can be checked against CVS records (turned out that it was not a hack, just an ill-advised comment that a Commiter had checked in). And those CVS records can be checked against replicated copies. It's far easier to oversee the source than the resulting HTML. In my experience, limited though it is, almost noone read the HTML commits, as they were assumed to be generated from the source. Those are just a few things that occur to me off-hand. I am sure that those who developed the policy in the first place have even more reasons, and experiences behind them. -- dIon Gillard, Multitask Consulting Blog: http://blogs.codehaus.org/people/dion/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Local changes to dbcp.html and pool.html can be removed. The cvs version is correct. -- Dirk Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Closer looking showed that these files had already been updated with cvs clashes. I've reset them to the local cvs. Thanks, Hen On Mon, 17 Nov 2003, Dirk Verbeeck wrote: Local changes to dbcp.html and pool.html can be removed. The cvs version is correct. -- Dirk Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Hen, I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
They are however in CVS, so if we do a cvs update it'll change those files. cvs server: Updating httpclient M httpclient/applications.html M httpclient/downloads.html M httpclient/features.html M httpclient/index.html M httpclient/news.html M httpclient/overview.html M httpclient/proposal.html M httpclient/status.html To fix the Lang url on sites, we need to cvs update a large number of files. Easy way to do that will be a simply 'cvs update'. Hen On Mon, 17 Nov 2003, Michael Becke wrote: Hen, I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? Mike On Nov 17, 2003, at 10:29 PM, Noel J. Bergman wrote: I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. As far as I know, all sites are supposed to be in CVS, and checked out into the file system. Amongst the reasons for this are to ensure that infrastructure can recover them rapidly in the event of a problem. This includes sites generated by Forrest or Maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [general] screwed up Commons site
Do you suggest removing the HttpClient docs from CVS? Mike On Nov 17, 2003, at 10:16 PM, Henri Yandell wrote: They are however in CVS, so if we do a cvs update it'll change those files. cvs server: Updating httpclient M httpclient/applications.html M httpclient/downloads.html M httpclient/features.html M httpclient/index.html M httpclient/news.html M httpclient/overview.html M httpclient/proposal.html M httpclient/status.html To fix the Lang url on sites, we need to cvs update a large number of files. Easy way to do that will be a simply 'cvs update'. Hen On Mon, 17 Nov 2003, Michael Becke wrote: Hen, I assume you are talking about the docs at /www/jakarta.apache.org/commons/httpclient/. The HttpClient site is not maintained in CVS. It is generated via Maven and published with maven site:deploy. What are you planning to do with the docs here? Mike On Nov 16, 2003, at 11:58 PM, Henri Yandell wrote: There are some problems on the Commons site cvs-wise at the moment. dbcp.html and pool.html have been edited locally. httpclient/ has also been edited locally. These will get merges when we do a cvs update to get the latest version of Lang out [as the url of the lang page is changing]. Not in itself a problem, but a potential one. More painfully, the Latka site has also been updated locally and has cvs clashes. If we do an update for Lang we're going to cause big problems here. DBCP, Pool, HttpClient could all just copy the files on minotaur over to a cvs repository that is not checked out as anonymous and commit them there. Latka needs more juggling. Any thoughts? Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
It seems there are a large number of commons sites that do not exist in CVS. Is there a standard for this? Should the HttpClient entries in CVS be removed? As far as I know, they should all be checked into CVS, regardless of whether they are built with anakia, forrest or maven. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [general] screwed up Commons site
Any thoughts? You want my view? As a matter of policy, changes that are not in CVS should not be considered changes. If you care to be nice, you could do cvs diff -u and e-mail the diff to the list before you blow the renegade file(s) away. --- Noel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
