CGI operates on W. rcs_commit() will commit from W to M.
+For all the gory details of how ikiwiki handles this behind the scenes,
+see [[commit-internals]].
+
You browse and web-edit the wiki on W.
CGI operates on R2. rcs_commit() will push from R2 to R1.
You browse the wiki on R1 and web-edit it on R2. This means for example
-that R2 needs to be updated from R1 if you are going the web-edit a page,
+that R2 needs to be updated from R1 if you are going to web-edit a page,
as the user otherwise might be irritated otherwise...
How do changes get from R1 to R2? Currently only internally in
-rcs_commit(). Is rcs_prepedit() suitable?
+rcs\_commit(). Is rcs\_prepedit() suitable?
It follows that the HTML rendering and the CGI handling can be completely
separated parts in ikiwiki.
repository is equal to the repository it was checked-out from. There is
no forced hierarchy.
-R1 is the nevertheless called the master repository. It's used for
+R1 is nevertheless called the master repository. It's used for
collecting all the changes and publishing them: on the one hand via the
rendered HTML and on the other via the standard darcs RCS interface.
-R2, the repository where CGI operates on, is just a checkout of R1 and
+R2, the repository the CGI operates on, is just a checkout of R1 and
doesn't really differ from the other checkouts that people will branch
off from R1.
shown in the file to resolve the conflict, so if you're already familiar
with that there's no new commit marker syntax to learn.
- For all the gory details of how ikiwiki handles this behind the scenes,
- see [[commit-internals]].
-
* page locking
Wiki admins can lock pages so that only other admins can edit them.