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
exportDescriptor.properties 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
backupattaachements).
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.
Joe
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:
MOVE A PAGE AND IT'S CHILDREN
- 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
COPY A PAGE
- 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
EXPORT / RESTORE
- 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
