doc/todo/darcs.mdwn

   1 <http://khjk.org/~pesco/ikiwiki-darcs/> (now a darcs repo)
   2
   3 > Note that there's a 'darcs' branch in git that I'm keeping a copy of your
   4 > code in. Just in case. :-)
   5
   6 I've taken all the good stuff from the above (now deleted --[[Joey]]) and added the missing hooks. The code hasn't seen a lot of testing, so some bugs are likely yet to surface. Also, I'm not experienced with perl and don't know where I should have used the function `possibly_foolish_untaint`.
   7
   8 > Review of this one:
   9 >
  10 > * Should use tab indentation.
  11 > * `rcs_getctime` should not need to use a ctime cache (such a cache should
  12 >   also not be named `.ikiwiki.ctimes`). `rcs_getctime` is run exactly
  13 >   once per page, ever, and the data is cached in ikiwiki's index.
  14 > * I doubt that ENV{DARCS} will be available, since the wrapper clobbers> the entire
  15 >   environment. I'd say remove that.
  16 > * I don't understand what `darcs_info` is doing, but it seems to be
  17 >   parsing xml with a regexp?
  18 > * Looks like `rcs_commit` needs a few improvements, as marked TODO
  19 > * `rcs_remove` just calls "rm"? Does darcs record notice the file was removed
  20 >    and automatically commit the removal? (And why `system("rm")` and not
  21 >    `unlink`?)
  22 > * Is the the darcs info in [[rcs/details]] still up-to-date re this version?
  23 > --[[Joey]]
  24
  25 > Update:
  26 >
  27 > I think I've addressed all of the above except for the XML parsing in `darcs_info`.
  28 > The function determines the md5 hash of the last patch the given file appears in.
  29 > That's indeed being done with regexps but my Perl isn't good enough for a quick recode
  30 > right now.
  31 >
  32 > As for the darcs info in [[rcs/details]], it does not accurately describe the way
  33 > this version works. It's similar, but the details differ slightly.
  34 > You could copy my description above to replace it.
  35 >
  36 >> done --[[Joey]]
  37 >
  38 > There is still some ironing to do, for instance the current version doesn't allow for
  39 > modifying attachments by re-uploading them via CGI ("darcs add failed"). Am I assuming
  40 > correctly that "adding" a file that's already in the repo should just be a no-op?
  41 > --pesco
  42
  43 >> It should result in the new file contents being committed by
  44 >> `rcs_commit_staged`. For some revision control systems, which
  45 >> automatically commit modifications, it would be a no-op. --[[Joey]]
  46
  47 >>> Done. --pesco
  48
  49 [[!tag patch]]