30 Mar
2007
30 Mar
'07
5:19 p.m.
vincent
That said, we've also opened a Google Summer of
Code project for this
(http://www.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Subversion+Integrati…).
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/