vincent
That said, we've also opened a Google Summer of Code project for this (http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Subversion+Integratio...). 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.
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.
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. Best, -- Hamish http://www.dcs.shef.ac.uk/~hamish/