Migrate escaped directives (\[[) in doc/todo to have \[[! prefix
[ikiwiki.git] / doc / todo / preprocessor_directive_for_proposed_changes.mdwn
1 There are some kind of changes to the underlying repository
2 which can't be made through the web interface:
3
4   * changes to files outside the wiki, to locked pages;
5   * advanced RCS operations such as merge, move, copy or del;
6   * changes you're not confident enough to apply outright.
7
8 Of course in these cases, you can add your request to a discussion page
9 and wait for someone with the access/confidence to apply them.
10 Maybe this can be enhanced with a [[ikiwiki/PreprocessorDirective]]:
11
12 <pre>
13 \[[!suggest op=merge dstfile=trunk srcfile=branches/jk oldrev=1234 newrev=1342]]
14
15 \[[!suggest op=move srcpage=/blog dstpage=/blog_support]]
16
17 \[[!suggest patch="""
18 Index: IkiWiki/CGI.pm
19 ===================================================================
20 --- IkiWiki/CGI.pm      (rĂ©vision 4119)
21 +++ IkiWiki/CGI.pm      (copie de travail)
22 @@ -497,9 +497,11 @@
23 (...)
24 """]]
25 </pre>
26
27 These would expand to a description of the changes,
28 and provide "apply theses changes", "preview changes", and maybe
29 "show diff" buttons. When those would be clicked,
30 an rcs_ function would be called to apply the changes in
31 the working copy, and depending on the request they would
32 be svn diff'ed or rendered and shown, and kept.
33 (all the affected pages would be inlined for the preview)
34
35 Ultimately my planned [[review_mechanism]] would manage pages
36 with such directives by itself.
37
38 Thinking about it, describing changes inside a directive rather
39 than as pages of their own is a bad remedy for the temporary
40 lack of web-based file upload in ikiwiki.
41
42 Implementing this as new pages formats would be simpler,
43 and combined with inlining and file uploading it would be
44 at least as powerful. It would be easier to handle changes
45 automatically (for instance, moving the change pages once
46 they have been applied). There would still be associated
47 discussion pages in markdown.
48
49 Regular pages could be used as change pages as well,
50 if they provide subpages in a format describing changes.
51 This would allow grouping and documenting changes.
52
53 I'm still uncertain about many things, so please anyone feel free to comment.
54 Specifically:
55
56   * Would it be possible to detect already applied changes
57     (without extra state, that is), and propose to "revert
58     changes" in that case?
59
60 --[[JeremieKoenig]]