geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: Documentation of new 2.2 features in current wiki?
Date Thu, 07 Aug 2008 21:00:27 GMT
This is some great information Dave.  Thanks for the details.

I experimented a little with export/restore but without much success.  I 
wasn't able to restore an image with an updated entities.xml (that 
simply replaced the old space references with new space references). 
Each time I attempted to restore it always complained that the was either missing or invalid ... but when I 
checked the file did exist and I didn't see anything obvious in there 
that needed to be changed when the space name was updated (actually, it 
only has something like 3 lines that were exportType, buildnumber, and 

It is really too bad that we can move an entire page tree but can only 
copy individual pages.  If only we could do that then it would be easy 
to integrate the 2.1 documents into a 2.2 space that was partially complete.


David Blevins wrote:
> On Jul 31, 2008, at 12:20 AM, David Jencks wrote:
>> My impression based on gossip is that while it's possible to copy an 
>> entire wiki space it isn't possible to move individual pages between 
>> spaces.  Is this correct?
> On Jul 31, 2008, at 3:38 PM, David Jencks wrote:
>>> 3. Create a new space for Apache Geronimo 2.2 (similar to the spaces 
>>> we have for 1.0, 1.1, 1.2, 2.0, and 2.1).  Add new documents specific 
>>> to 2.2 into this new space.  It would be fairly sparse for now.  When 
>>> we complete the 2.1 docs we can clone them into the 2.2 space and 
>>> integrate the 2.2 specific documents into the appropriate 
>>> sections/structure.
>> My impression from the 2.1 debacle of not starting by copying the 
>> existing documentation into a new 2.1 space was that after the space 
>> was created, you couldn't copy stuff from another space en mass. 
>> Hopefully I'm wrong.  Anyway this hopefully mis-understanding is the 
>> basis for (1).
> What confluence can do:
>    - From a page's "Edit" tab, click the smaller edit link by 
> "Location".  You can then change the space or parent page.  If you 
> select a new space, a checkbox becomes available that allows you to 
> optionally change the space of all children pages.
>    - Cascades to children: optional
>    - Retains edit history: yes
>    - Retains attachments: yes
>    - Retains comments: yes
>    - Retains labels: yes
>    - Retains permissions: yes
>    - From a page's "Info" tab, click the "Copy" link.  You get a new 
> edit screen with the current page content and a the title with "Copy of 
> " prepended to it.  All the normal things can be edited from this 
> screen, including "Location".
>    - Cascades to children: no
>    - Retains edit history: no
>    - Retains attachments: yes
>    - Retains comments: no
>    - Retains labels: no
>    - Retains permissions: no
>    - From a space's "Advanced" tab, click "Export Space".  You can 
> select any pages you want and export as XML.  Then you need to crack 
> open the zip downloaded and exit the entities.xml to change the space 
> name.  Zip the whole thing up again and use the Restore option as a 
> confluence administrator.  Note you cannot use the restore option on 
> spaces that already exist.
>    - Retains edit history: yes
>    - Retains attachments: yes
>    - Retains comments: yes
>    - Retains labels: no (didn't work for me)
>    - Retains permissions: yes
> My thoughts:
> If we really want a separate space for each major version, then I'd 
> recommend we use the EXPORT/RESTORE option to seed from the prior 
> version's space (2.1).  If we need to create any pages before then, 
> which seems to be our current dilemma, then we can create a "2.2" page 
> somewhere else (say DEV or SANDBOX or anywhere) and make all such new 
> content a child of that page.  Whenever we do eventually create a "2.2" 
> space we can move then "2.2" page and all it's children from the 
> temporary space to the "2.2" space in one operation.
> The two main reasons:
>   1. I think author/revision history is critical for oversight.
>   2. Efficiency.  If N is the number of pages we have from the the prior 
> version's space and X is the number pages that are new for the current 
> version's space, N is going to always get bigger and bigger and more and 
> more disproportionate to X.  Mathematically starting with a space seeded 
> from the N pages and moving in X pages requires less operations than 
> starting with a new space for X and copying in N pages, which will only 
> get worse over time.  Further, the cost of moving X can be reduced to 1 
> if we use the parent page and move children trick.
> I understand that one of the motivations for starting blank and copying 
> pages individually was to allow for review of the pages to see if they 
> are still relevant.  That's an orthogonal argument as a review process 
> of "review then copy" would take an equal amount of time as a "review 
> then delete" process.  The real difference is in weather or not pages 
> should be considered "relevant" or "outdated" by default and which risk 
> is worse; the potential for missing valid documentation or the potential 
> for present invalid documentation.  But as I say, the amount of time to 
> review and remedy is the same, though I do think that users are more 
> likely to help point out invalid documentation that we can delete or 
> update than they are to help review and copy valid documentation.
> As large as this email is, it's not necessarily complete.  The question 
> of when do we really need a new base for documentation is an important 
> one.  Is there enough change between 2.1 and 2.2 to merit a new space or 
> can that be delated till later?
> -David

View raw message