On 10 December 2012 21:53, Phil Steitz <phil.ste...@gmail.com> wrote: > On 12/10/12 1:27 PM, Ralph Goers 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. > > Sorry, I don't get it. Why won't the following work: > > 0) Grab all of, say p.a.o/www/commons.apache.org > 1) check all of that into an svn repo > 2) when I want to update, say, math, I generate the content locally, > copy it to the /math subtree and check it in.
There would need to be some extra work done to ensure that stale files are deleted. For some projects, it would be possible to just delete the existing sub-tree and check the whole new site in. [This can be done as one transaction in svnmucc] However, for sites that retain Javadoc etc. for older releases, one would need to re-instate that part of the tree somehow. Given that svnpubsub immediately publishes what is checked in, it might be sensible to have a parallel staging directory tree where files can be updated piecemeal if necessary, and then use svnmucc to replace the live component subtree with the staging component subtree as part of a single transaction. There would need to be some co-ordination between committers when updating commons parent, as that would affect the whole tree. > I guess this is not "proper" from the maven perspective because it > does not use maven deployment. No big loss, IMHO. Am I missing > something else? > > Phil > >> >> 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 >> >> > > > --------------------------------------------------------------------- > 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
