How about having an entire site's state snapshotted as a release or branch (in subversion). You could then (1) fetch the next "site release tag", (2) xml-transform all markup, (3) build the associated xml documents, (4) create the package.xml manifest, (5) 'zip/jar' it up as a Xar, then (6) import via LargeXARImportScriptSnippet<http://code.xwiki.org/xwiki/bin/view/Snippet… in "one-click" have the entire site (or staging server) upgraded to a new release. One should also be able to go the other direction -- have an existing Xwiki site, and a Space.Doc>filename mapping so that an existing site/package/or/space can be snapshotted into subversion, and saved as a new branch. I would imagine the application manager would be the component which constructs the mappings from Space.Doc- > svn filename from the user's entries. People preferring to edit in richer editing environments may prefer this because they can use their favorite syntax highlighting<http://wiki.apache.org/velocity/EmacsVtlMode>and built in revision-control integration. (i prefer xemacs <http://xemacs.org/> and various extensions that allow it to save or load snapshots from a variety of revision control systems, including subversion<http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&… ). By saving the non-Xml transformed HTML data into the revision control system, this becomes possible -- do all the transforms and packaging on-the-fly as part of the xar construction and importing process. One could use this approach to easily snapshot a release from a development server, move it to a production server, make any fixes to the current "branch" and when ready to release, snapshot that branch and move to the "live server." Finally, it wouldn't hurt to have an extra "backup" that sensibly snapshots the state of multiple xwiki subcomponents comprising a package or release. Often the "granularity" of changes saved in Xwiki's history (whch is great to have, I'm not complaining) is too "fine" -- especially if you're "rapid prototyping" ... and there's no way to specify that revision 743 of file #1 corresponds to revision 321 of file #2, called from #1.... Speaking of subversion... FYI, Karl Fogel's employment interview at Collabnet happened at my house in SF, back when I lived there and worked there (ca 2000 employee# < 10). My cat decided to get stuck on the neighbor's balcony immediately before the interview, and Karl found her loud meowling annoying enough that he interrupted the interview, climbed up the tree onto the 2ond story balcony (given the slope of the street, it was > 3 stories), and successfully rescued the cat, then completed the interview... He got the job, and I called the fire department to cancel the cat-rescue.... :-) Niels http://nielsmayer.com On Sat, Jun 20, 2009 at 3:34 AM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote:

On Sun, Jun 21, 2009 at 4:58 AM, Vincent Massol &lt;vincent(a)massol.net&gt; wrote: Re state snapshot of versions we want to do this but with the new model/storage using JCR. See http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20 [...] I don't think this is related to the extension manager which role should be to import/export XARs. Whether the XAR is built from SVN or some other mechanism is independent IMO. [...] Again for me this is about implementing a storage based on SVN. When we have JCR support all we'd need is a JCR implementation for SVN (I looked some time ago and couldn't find one though). alongside xwiki's existing versioning system (not replacing it). It reuses existing social practices and implementations associated with the delivery of packaged software products (or websites) out of a branched repository. The application manager would subsume and hide the implementation details, and simply make it easy to snapshot a whole set of documents that comprise a release (each at a particular xwiki revision number) and make that snapshot "open" to anything that can talk to subversion on the back-end. For example, Xwiki.org&com has clearly found benefit from having a release process based on branches in subversion. And there are a number of scripts used to automate the generation of a "build" and various releases for Xwiki from the repository. It would be nice to be able to replicate this "type" of process, for websites, for spaces, or packages of Xwiki documents. But without exposing much underlying details of the back-end revision control system -- and a nice and simple UI to drive it all as a "one click" process. What I was suggesting is that this kind of bigger-picture use-case be considered in the application-manager. In other words, change "I don't think this is related to the extension manager which role should be to import/export XARs. Whether the XAR is built from SVN or some other mechanism is independent IMO." to "Using a 'branched release' model be able to import/export XARs. This implementation is entirely Independent of Xwiki's underlying storage (therefore future compatible with WikiModel20<http://dev.xwiki.org/xwiki/bin/view/Design/XWikiModel20>)0>), and probably implemented as an independent application that talks REST/HTTP to Xwiki, and makes direct use of an existing subversion repository as the back-end. For compatibility with the widest number of tools, and in order to reuse as much code as possible, this application-manager-application (separate app from the Xwiki instance being "managed") would make use of an existing, standard, instance of a subversion repository (e.g. implemented via apache httpd) and work alongside standard access-control and authentication mechanisms used for the repository." Niels http://nielsmayer.com