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