[daisy] "A document ID can only be specified for foreign namespaces, which DSY is not."

[Robert Cecil]

Hi folks,

I will apologize up front for my long-ish post; I hope someone has  
the patience to read through my blathering and provide some thoughts. :)


I am trying to use the new Daisy 2.0 import/export tool in a way  
possibly not fully imagined by its creators. Here's my situation: I  
have a set of developers who each an instance of Daisy-2.0 installed  
on their local computers. A central "build" machine is maintained,  
primarily for QA purposes and to demonstrate project progress to the  
client on regular basis. Developers will typically do the following:  
create custom doctypes, create custom forms (cforms) and other Daisy  
extensions, create/modify skins and create content (primarily  
navigation documents, and placeholder documents). At some point in  
the future this project will be deployed in a hosting environment,  
and the client will assume responsibility for maintaining their own  
content (obviously). Until then, my dev team is creating small bits  
of content, along with the other project artifacts mentioned above.

I thought the Daisy 2.0 export/import tool would allow for us to  
version the 'logical' content in the site: documents, doc types  
(schema), etc, and support parallel work on the site. My thought  
process would be something like:

1. Developer checks out via SCM the module for the project containing  
the current Wiki directory (sites, resources, skins), plus the last  
export directory structure (documents, info, etc)
2. Developer runs import on local machine to update his/her private  
MySQL instance with the most recent documents and schema information  
from SCM.
3. Developer runs a script (or manually) any updates to the various  
Wiki sites folders, resource folders, etc, depending on the situation
4. Developer's local Daisy instance reflects the most recent team  
commits to all of these artifacts and continues working.
5. When the time is right, the developer runs Export on his/her own  
local Daisy instance, reconciles the output of the export against his/ 
her CVS workspace, and updates any Wiki folder changes for  
programmatic/functional changes.
6. Developer runs CVS Update reconciles conflicts, and then commits  
all work.
7. At a predetermined time and schedule, someone logs on the central  
build server, runs CVS update, which updates the CVS workspace on the  
server to grab all the recent checkins of both Wiki folder stuff, and  
any checkins to Daisy site Export output.
8. The person runs Daisy Import to import all CVS changes into the  
shared central MySql instance, thereby synchronizing any documents  
and schema changes

This all hinges on the namespace and namespace fingerprint for the  
developers local Daisy instance and the central Daisy build to be  
identical. Or so I thought. I am getting the errors:

<document id="24-DSY" branch="main" language="default">
<description>A document ID can only be specified for foreign  
namespaces, which DSY is not.</description>
<stackTrace>(stacktraces disabled, enable them via import options)</ 
stackTrace>
</document>

When I attempt to test this process.

Apparently, my idea of faking out identical namespaces across  
machines is backfiring. It won't let me import what it thinks are  
documents that should already be in the instance??

I suspect that I'm approaching the tool the wrong way. And if so, how  
are other teams approaching building a Daisy system over a project  
development period, and maintain sanity?

Thanks
Rob Cecil



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cocoondev.org/pipermail/daisy/attachments/20061210/9f5ac0d5/attachment.html