commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <ralph.go...@dslextreme.com>
Subject Re: We will not be able to update our websites...
Date Mon, 10 Dec 2012 18:50:32 GMT
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 <garydgregory@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 <grobmeier@gmail.com>
wrote:
>>>> 
>>>>> On Mon, Dec 10, 2012 at 1:07 PM, Gary Gregory <garydgregory@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 <grobmeier@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-unsubscribe@commons.apache.org
>>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> http://www.grobmeier.de
>>>>> https://www.timeandbill.de
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>> 
>>> 
>>> --
>>> http://www.grobmeier.de
>>> https://www.timeandbill.de
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message