Ralph, Thanks for your response, and sorry if I'm still being dense, but let's just use the [lang] component as an example. Why can't I, at any point, generate the component's site locally, then surgically modify svn so that lang/ from the content root now contains the generated content? Where does a diff become necessary?
Matt On Mon, Dec 10, 2012 at 3:27 PM, Ralph Goers <ralph.go...@dslextreme.com>wrote: > 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 > >> > >> > >
