geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <>
Subject Re: Documentation of new 2.2 features in current wiki?
Date Fri, 01 Aug 2008 19:31:56 GMT

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?


View raw message