toc
[ikiwiki.git] / doc / about_rcs_backends.mdwn
1 A few bits about the RCS backends
2
3 [[toc ]]
4
5 ## Terminology
6
7 ``web-edit'' means that a page is edited by using the web (CGI) interface
8 as opposed to using a editor and the RCS interface.
9
10
11 ## [[Subversion]]
12
13 Subversion was the first RCS to be supported by ikiwiki.
14
15 ### How does it work internally?
16
17 Master repository M.
18
19 RCS commits from the outside are installed into M.
20
21 There is a working copy of M (a checkout of M): W.
22
23 HTML is generated from W.  rcs_update() will update from M to W.
24
25 CGI operates on W.  rcs_commit() will commit from W to M.
26
27 For all the gory details of how ikiwiki handles this behind the scenes,
28 see [[commit-internals]].
29
30 You browse and web-edit the wiki on W.
31
32
33 ## [darcs](http://darcs.net/) (not yet included)
34
35 Support for using darcs as a backend is being worked on by [Thomas
36 Schwinge](mailto:tschwinge@gnu.org).
37
38 ### How will it work internally?
39
40 ``Master'' repository R1.
41
42 RCS commits from the outside are installed into R1.
43
44 HTML is generated from R1.  HTML is automatically generated (by using a
45 ``post-hook'') each time a new change is installed into R1.  It follows
46 that rcs_update() is not needed.
47
48 There is a working copy of R1: R2.
49
50 CGI operates on R2.  rcs_commit() will push from R2 to R1.
51
52 You browse the wiki on R1 and web-edit it on R2.  This means for example
53 that R2 needs to be updated from R1 if you are going to web-edit a page,
54 as the user otherwise might be irritated otherwise...
55
56 How do changes get from R1 to R2?  Currently only internally in
57 rcs\_commit().  Is rcs\_prepedit() suitable?
58
59 It follows that the HTML rendering and the CGI handling can be completely
60 separated parts in ikiwiki.
61
62 What repository should [[RecentChanges]] and [[History]] work on?  R1?
63
64 #### Rationale for doing it differently than in the Subversion case
65
66 darcs is a distributed RCS, which means that every checkout of a
67 repository is equal to the repository it was checked-out from.  There is
68 no forced hierarchy.
69
70 R1 is nevertheless called the master repository.  It's used for
71 collecting all the changes and publishing them: on the one hand via the
72 rendered HTML and on the other via the standard darcs RCS interface.
73
74 R2, the repository the CGI operates on, is just a checkout of R1 and
75 doesn't really differ from the other checkouts that people will branch
76 off from R1.
77
78 (To be continued.)
79
80 #### Another possible approach
81
82 Here's what I (tuomov) think, would be a “cleaner” approach:
83
84  1. Upon starting to edit, Ikiwiki gets a copy of the page, and `darcs changes --context`.
85      This context _and_ the present version of the page are stored in as the “version” of the
86      page in a hidden control of the HTML.
87      Thus the HTML includes all that is needed to generate a patch wrt. to the state of the
88      repository at the time the edit was started. This is of course all that darcs needs.
89  2. Once the user is done with editing, _Ikiwiki generates a patch bundle_ for darcs.
90      This should be easy with existing `Text::Diff` or somesuch modules, as the Web edits
91      only concern single files. The reason why the old version of the page is stored in
92      the HTML (possibly compressed) is that the diff can be generated.
93  3. Now this patch bundle is applied with `darcs apply`, or sent by email for moderation…
94      there are many possibilities.
95
96 This approach avoids some of the problems of concurrent edits that the previous one may have,
97 although there may be conflicts, which may or may not propagate to the displayed web page.
98 (Unfortunately there is not an option to `darcs apply` to generate some sort of ‘confliction resolution
99 bundle’.) Also, only one repository is needed, as it is never directly modified
100 by Ikiwiki. 
101
102 This approach might be applicable to other distributed VCSs as well, although they're not as oriented
103 towards transmitting changes with standalone patch bundles (often by email) as darcs is.
104
105 ## [[Git]]
106
107 Regarding the Git support, Recai says:
108
109 I have been testing it for the past few days and it seems satisfactory.  I
110 haven't observed any race condition regarding the concurrent blog commits
111 and it handles merge conflicts gracefully as far as I can see.
112
113 As you may notice from the patch size, GIT support is not so trivial to
114 implement (for me, at least).  Being a fairly fresh code base it has some
115 bugs.  It also has some drawbacks (especially wrt merge which was the hard
116 part).  GIT doesn't have a similar functionality like 'svn merge -rOLD:NEW
117 FILE' (please see the relevant comment in mergepast for more details), so I
118 had to invent an ugly hack just for the purpose.
119
120 ## [mercurial](http://www.selenic.com/mercurial/)
121
122 Being worked on by Emanuele Aina.
123
124 <http://techn.ocracy.org/ikiwiki>