Hi, We use ZCVSFolder here at www.CodeWorks.lt extensively, and we've been contributing patches to it. One of the main chores with ZCVSFolder is the unreadability of XML-exported files (random object IDs, random reorderings of document nodes, escape sequences in document bodies etc.). This makes the XMLs basically unreadable, undiffable and unmergeable. As an alternative we developed an alternative export format, which resembles RFC-822 a lot. Here's an example of an exported Python script: Bindings: container='container' context='context' namespace='' script='script' subpath='traverse_subpath' Id: language_buttons Local-Roles: mg=('Owner',) Meta-Type: Script (Python) Owner: acl_users mg Parameters: Permissions: Proxy-Roles: Title: # Example code: # Import a standard function, and get the HTML request and response objects. from Products.PythonScripts.standard import html_quote request = container.REQUEST RESPONSE = request.RESPONSE # Return a string identifying this script. print "This is the", script.meta_type, '"%s"' % script.getId(), if script.title: print "(%s)" % html_quote(script.title), print "out", container.absolute_url() return printed Advantages: - This format is compact, easily readable, diffable and mergeable - It contains only relevant object attributes, instead of being a dump of internal representation (e.g. storing both source code and base64-encoded compiled bytecode for Python scripts in exported XML files) Disadvantages: - Export of different object types is no longer automatic, you have to write code for every supported meta-type (only about 20 lines of Python for every supported meta-type on average). - The code may drift, e.g., when new attributes are added into Zope objects but import/export is not updated. This may cause maintainability problems. I am now starting to think about future possibilities. If such a representation would get officially endorsed and included into Zope proper, and import/export routines were added to the objects themselves, it would eliminate the second disadvantage (code drift). There would also be a standard interface to get to a plaintext representation of both data and metadata, more extensive than document_src(). The possibilities are endless. It would be nice to be able to connect to a running zope instance via FTP/whatever and get and edit objects in this format. This would allow the users to see/change metadata also. There would no longer be a need for PUT_factory external methods for creating new objects of various kinds. What do you think about this? BTW if anyone wants to see the actual code, take a look into ZCVSFolder CVS repository (cvs.zcvsfolder.sourceforge.net module zcvsfolder), mg-patches branch. It will be merged into main branch in a week if Steve Spicklemire approves. I suppose I could make the code available on the web somewhere if there's any interest. Marius Gedminas -- If C gives you enough rope to hang yourself, C++ gives you enough rope to bind and gag your neighborhood, rig the sails on a small ship, and still have enough rope left over to hang yourself from the yardarm.