git.oblomov.eu Git - ikiwiki/blob - 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/Directive]]:
  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]]