Yes, I think you are missing something fundamental. If you check in "the whole mess" you will never again be able to properly build a sub-project's site with Maven. This is because the process of updating the site would require first doing a diff and then deleting items that are not included in the new version. Someone created a Maven plugin to try to do this but it is not the way I would want to go at all.
Ralph On Dec 10, 2012, at 11:49 AM, Matt Benson wrote: > I don't think there's much percentage in moving to the CMS with a structure > like that of Commons. That said, checking in the whole mess, as Phil > suggests, seems perfectly doable and should not preclude updating parts of > the tree in quite a similar fashion as how updating a given component's > site is done today, except no ssh to mino. Am I missing something > fundamental? > > Matt > > > On Mon, Dec 10, 2012 at 1:47 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > >> On 12/10/12 11:40 AM, Phil Steitz wrote: >>> On 12/10/12 10:50 AM, Ralph Goers wrote: >>>> All the sub-sites are hooked off the main site. I would have no idea >> how to migrate anything without migrating the main site first. >>> Having now looked at [1], it looks to me like we can solve the >>> immediate problem using svn pub-sub. The docs are not clear and >>> they may not allow it, but in theory, we could in fact do this >>> incrementally - start an svn repo and move the "mutable" portions >>> there incrementally, understanding that only changes to the >>> svn-migrated stuff will be propagated. If infra barfs on that, then >>> we just commit the whole mess starting at the top level commons >>> site, following the Ant example linked on [1]. Then to make >>> changes, we follow the process that has been in place for the main >>> ASF site for ages - maintain a local checkout of the generated site, >>> re-gen when you want to update and check in. >>> >>> I know playing with the CMS might be fun and interesting; but a) we >>> have no volunteers to do this and b) we do not have time to migrate >>> all of the content. >>> >>> Therefore, I suggest we just follow the Ant route; possibly moving >>> incrementally if infra allows that. >> >> Let me modify the proposal to make it simpler and more palatable to >> infra: >> >> Just do like Ant - check in the whole mess. >> >> Phil >>> >>> Phil >>> >>> [1] http://www.apache.org/dev/project-site.html >>>> I suppose it is possible to point to the sub-sites in their current >> location but in logging we found it more beneficial to simply copy the >> content under the main site in the CMS. >>>> >>>> Are all the sub-sites built with Maven? Any that are not could move to >> the CMS as part of the main site. >>>> >>>> Ralph >>>> >>>> >>>> On Dec 10, 2012, at 8:23 AM, Phil Steitz wrote: >>>> >>>>> On 12/10/12 7:55 AM, Ralph Goers wrote: >>>>>> That is what we did in logging. Changing it at the end is fairly >> easy. However, we don't have much time for testing. >>>>> Do we really have to do it all at once? >>>>> >>>>> IIUC (which is quite possibly false), the intent here is to get >>>>> everyone onto svn pub-sub and kill off the rsync processes from >>>>> p.a.o to the live site. The stake in the ground is that the rsyncs >>>>> are going to stop Jan 1. Do I have that right? >>>>> >>>>> Why can't we move to svn pub-sub incrementally somehow, >>>>> understanding that until individual components move, their sites >>>>> will be read-only? So basically, when you decide to make changes to >>>>> a site, you get it set up for svn pub-sub? Note I am including the >>>>> main site in this - i.e., it does not have to "move" until it needs >>>>> to be changed. It would seem to me (again, may be missing something >>>>> critical) that we could build the newly definitive source svn repo >>>>> incrementally, with publishing always sourced from there, but "old" >>>>> directories on the live host remaining until they get clobbered. In >>>>> the worst case, if the live host *must* include only svn-published >>>>> files, we could seed the new repo with the "old" content. But I >>>>> don't get why that has to be the case; because if it is, we are in >>>>> worse shape than Christian suggests - come Jan 1 we will be dark if >>>>> we don't get everything moved to svn pub-sub. >>>>> >>>>> Sorry if above is naive. The intent is to avoid a huge amount of >>>>> fiddling in a short period of time when quite a few component sites >>>>> have not changed and will not change for some time to come. >>>>> >>>>> Phil >>>>> >>>>> >>>>>> Ralph >>>>>> >>>>>> On Dec 10, 2012, at 4:34 AM, Christian Grobmeier wrote: >>>>>> >>>>>>> On Mon, Dec 10, 2012 at 1:32 PM, Gary Gregory < >> garydgreg...@gmail.com> wrote: >>>>>>>> Well, we have to start somewhere. This is going to be a lot of work, >>>>>>>> we have many components, unless you see a short cut. >>>>>>> I thought we would create: commons-test.apache.org >>>>>>> move all components to there and then make a switch from >>>>>>> commons.apache.org to the new site >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> On Dec 10, 2012, at 7:13, Christian Grobmeier <grobme...@gmail.com> >> wrote: >>>>>>>> >>>>>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory < >> garydgreg...@gmail.com> wrote: >>>>>>>>>> Bah, let's pick one component and start there and skip a test >> site. >>>>>>>>> But then there is only one component visible under the new >> commons.a.o? >>>>>>>>> >>>>>>>>>> Gary >>>>>>>>>> >>>>>>>>>> On Dec 10, 2012, at 3:08, Christian Grobmeier < >> grobme...@gmail.com> wrote: >>>>>>>>>> >>>>>>>>>>> starting from 1. January. Just saw a final reminder from Infra. >>>>>>>>>>> >>>>>>>>>>> Commons is surely a LOT of work. >>>>>>>>>>> >>>>>>>>>>> I would like to suggest we act immediately. >>>>>>>>>>> >>>>>>>>>>> In other terms: let us request a commons-test cms where we can >> try things >>>>>>>>>>> out and prepare the new sites. >>>>>>>>>>> >>>>>>>>>>> As Ralph Goers has already mentioned, we have a similar >> structure in >>>>>>>>>>> logging land (1 main site, several sub sites) which might fit to >> Commons >>>>>>>>>>> too. >>>>>>>>>>> >>>>>>>>>>> Basically we have the Main-Site under CMS control; the subsites >> are >>>>>>>>>>> generated via Maven. The target of this generation is then >> copied to >>>>>>>>>>> another svn tree from which it will be taken and published. >>>>>>>>>>> >>>>>>>>>>> Obviously we will have to generate sites for each component >> then, which >>>>>>>>>>> will be a tough job with x-mas arriving. >>>>>>>>>>> >>>>>>>>>>> Thoughts? >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> http://www.grobmeier.de >>>>>>>>>>> https://www.timeandbill.de >>>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>>> >>>>>>>>> -- >>>>>>>>> http://www.grobmeier.de >>>>>>>>> https://www.timeandbill.de >>>>>>>>> >>>>>>>>> >> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>>> >>>>>>>> >> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>>> >>>>>>> -- >>>>>>> http://www.grobmeier.de >>>>>>> https://www.timeandbill.de >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
