The current design checks out the current sub-site into a subdir of "target", runs the build using that data (which represents the existing features and plugins, including any previous "versions"), and then allows committing (just) the changes back to the current sub-site.
A modification (for safety) has been to use the dist.apache.org's "dev" tree, rather than the "release" tree, and require some kind of intentional "manual" operation to release the update site. This is currently done as follows (under the -Papache-release profile): 1) svn delete the update subsite on the dist.apache.org ... dev. 2) svn copy the update subsite from the ...release... to the ...dev... (this is because svn copy won't copy over existing dirs). I think the following would work better: 1) check out the subsite from the ...dev... side. 2) svn merge the subsite from the ...release... side. This makes it up-to-date with the release side. At this point the working copy is equivalent to the release side. With this approach, there's no need to do 2 svn change operations on dist.apache.org repository (the delete, and the copy). Any objections to changing the parent pom to work this way, or better suggestions? -Marshall
