On 3/30/07, Hamish Cunningham <hamish@dcs.shef.ac.uk> wrote:

vincent

> That said, we've also opened a Google Summer of Code project for this
> ( http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Subversion+Integration).
> If you're interested you could work with your team and that person on

sounds good!

> 1) It's probably better to decide what pages are stored in SVN and which
> pages are stored in the wiki. Indeed some pages such as Classes probably
> don't need to be stored in SVN
> 2) We need to allow storing the page content separately from the rest of
> the metadata (class definition, objects, etc)

I agree that not all of the data needs to be in SVN, but I think it would be
nice if some of the textual content of pages was available for external
editing and so on. An advantage of pushing all the data out into some textual
form (even if it isn't very readable) is that you could then use SVN
replication (or just checking out another copy) to duplicate a site, and
branching for experimenting with a new approach, etc.

Since the wiki documents can be retrieved as XML, separating the document content and document metadata is an easy task, which can be performed with many possible methods: SAX, DOM, XSLT. Moreover, since your documents will mainly contain text, without the need for objects and classes, it might be a good idea to store just the content and simple metadata (author and modification time) in SVN. Even more, XWiki has the notion of spaces, or a group of related documents. You can put all your documents in spaces which don't have any XWiki-related content (special class documents, or templates), and only sync these spaces with the SVN repository.

About branching XWiki can be of use in here, since it supports setting up virtual wikis on the same server.

> Obviously one issue is that if we do a svn update before editing a
> document (to check if there's a newer version) that'll affect
> performances. Thus we might want to schedule updates regularly or offer
> a button for the user to do that. In any case it means we need to cater
> for SVN merge conflicts and offer a solution for that.
>
> Anyone has any other idea?

One option is to get the SVN server to hit a URL whenever anything changes and
trigger import of the changes at that point. Some other mechanism (like the
scheduled update you propose) is also necessary to cope with network outages etc.

This is a good idea. I know that SVN allows registering a kind of listeners (Hook Scripts is the term they use) which can be triggered before or after committing files. One hook could be used to re-get the content from the wiki when starting the commit, and one could be used to update the wiki after the commit. See http://svnbook.red-bean.com/en/1.0/ch05s02.html#svn-ch-5-sect-2.1 for more details.

> I suggest we gather ideas here on the list and when we have some
> agreement we can start putting those on a wiki page on xwiki.org.
> Hamish, I'd be happy if you wanted to drive this effort.

I'd like to participate; at present I don't understand well how xwiki works,
so I'm not sure I'm the right person to drive it.

> Actually Christian and Nam are developing one right now. It would be
> cool if you could have a look and possibly help them. It's in SVN in
> xwiki/branches/XWIKI_WYSIWYG_NEWARCHI/core/src/main/java/com/xpn/xwiki/wysiwyg

We're using a different syntax (see attached) and allowing embedding of
controlled language statements for ontology editing
(http://gate.ac.uk/sale/lrec2006/clie/clie.pdf). Actually if I was going to do
this again (write a wiki parser) I'd be tempted not to use JavaCC, which is
great for fully deterministic parsing but difficult when you want to return a
reasonable translation of messy data even when the author has made mistakes.
Our JAPE regular expressions over annotation graphs tool might have been
easier (http://gate.ac.uk/, imperfectly documented in
http://gate.ac.uk/sale/tao/index.html), but I've invested too much time in the
JavaCC version now!

So this wouldn't replace your existing parser efforts, but I'd like to try and
make it an optional syntax.

This is easy to accomplish. For most of these items there are existing filters, only the syntax must be changed, and the rest of them are easy to add.

In order to change the syntax, you just need to change a file, core/src/main/resources/radeox_markup_xwiki.properties. In order to add new filters, I think there is a page describing this on www.XWiki.org. Anyway, it's not hard at all.

Best,
--
Hamish
http://www.dcs.shef.ac.uk/~hamish/