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. 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
