]> git.vanrenterghem.biz Git - git.ikiwiki.info.git/blobdiff - doc/todo/Mercurial_backend_update.mdwn
comments: Write pending moderation comments to the transient underlay to avoid confli...
[git.ikiwiki.info.git] / doc / todo / Mercurial_backend_update.mdwn
index 717db61b5522ed1b9de4a934d510f97ffa11a8a8..d98a4ea6864bad91142caeff8a22cc3bf8708d3d 100644 (file)
@@ -2,7 +2,40 @@ I submitted some changes that added 5 "Yes"es and 2 "Fast"s to Mercurial at [[/r
 
 To do this, a more basic rewrite would simplify things. I inline the complete file below with comments. I don't expect anyone to take the time to read it all at once, but I'd be glad if those interested in the Mercurial backend could do some beta testing.
 
 
 To do this, a more basic rewrite would simplify things. I inline the complete file below with comments. I don't expect anyone to take the time to read it all at once, but I'd be glad if those interested in the Mercurial backend could do some beta testing.
 
-I break out my comments from the code to make them more readable. I comment all the changes as compared to current upstream.
+* [This specific revision at my hg repo](http://46.239.104.5:81/hg/program/ikiwiki/file/4994ba5e36fa/Plugin/mercurial.pm) ([raw version](http://46.239.104.5:81/hg/program/ikiwiki/raw-file/4994ba5e36fa/Plugin/mercurial.pm)).
+
+* [My default branch](http://510x.se/hg/program/ikiwiki/file/default/Plugin/mercurial.pm) (where updates will be made, will mention here if anything happens) ([raw version](http://510x.se/hg/program/ikiwiki/raw-file/default/Plugin/mercurial.pm)).
+
+(I've stripped the `hgrc`-generation from the linked versions, so it should work to just drop them on top of the old `mercurial.pm`).
+
+I break out my comments from the code to make them more readable. I comment all the changes as compared to current upstream. --[[Daniel Andersson]]
+
+> So, sorry it took me so long (summer vacation), but I've finally
+> gotten around to looking at this. Based mostly just on the comments,
+> it does not seem mergeable as-is, yet. Red flags for me include:
+> 
+> * This is a big rewrite, and the main idea seems to be to copy git.pm
+>   and hack on it until it works, which I think is unlikely to be ideal
+>   as git and mercurial are not really similar at the level used here.
+> * There have been no changes in your hg repo to the code since you
+>   originally committed it. Either it's perfect, or it's not been tested..
+> * `hg_local_dirstate_shelve` writes to a temp file in the srcdir,
+>   which is hardly clean or ideal.
+> * Relies on mercurial bookmarks extension that seems to need to be
+>   turned on (how?)
+> * There are some places where code was taken from git.pm and the
+>   comment asks if it even makes sense for mercurial, which obviously
+>   would need to be cleaned up.
+> * The `rcs_receive` support especially is very ambitious to try to add to
+>   the mercurial code. Does mercurial support anonymous pushes at all? How
+>   would ikiwiki be run to handle such a push? How would it tell 
+>   mercurial not to accept a push if it made prohibited changes?
+>
+> I'm glad we already got so many standalone improvements into
+> mercurial.pm. That's a better approach than rewriting the world, unless
+> the world is badly broken. 
+> 
+> --[[Joey]] 
 
 ---
 
 
 ---
 
@@ -26,7 +59,7 @@ Message to skip in recent changes
 
                my $dummy_commit_msg = 'dummy commit';
 
 
                my $dummy_commit_msg = 'dummy commit';
 
-*TODO:* $hg_dir not really implemented yet, until a srcdir/repository distinction is
+*TODO:* `$hg_dir` not really implemented yet, until a srcdir/repository distinction is
 made as for e.g. Git. Used in `rcs_receive`, and for attachments in `hg_parse_changes`. See comments in those places, though.
 
                my $hg_dir=undef;
 made as for e.g. Git. Used in `rcs_receive`, and for attachments in `hg_parse_changes`. See comments in those places, though.
 
                my $hg_dir=undef;
@@ -201,7 +234,7 @@ This function restores the diff.
                        }
                }
 
                        }
                }
 
-This makes online diffing possible. A similar approach as in `git.pm`, which is [http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Plugin/git.pm;h=cf7fbe9b7c43ee53180612d0411e6202074fb9e0;hb=refs/heads/master#l211](discussed to some length in a comment there), is taken.
+This makes online diffing possible. A similar approach as in `git.pm`, which is [discussed to some length in a comment there](http://source.ikiwiki.branchable.com/?p=source.git;a=blob;f=IkiWiki/Plugin/git.pm;h=cf7fbe9b7c43ee53180612d0411e6202074fb9e0;hb=refs/heads/master#l211), is taken.
 
                sub merge_past ($$$) {
                        my ($sha1, $file, $message) = @_;
 
                sub merge_past ($$$) {
                        my ($sha1, $file, $message) = @_;
@@ -725,6 +758,11 @@ This is an upstream change I did a week ago or so. Perhaps it can be merged in s
 
 The comment just below the function declaration below is taken from `git.pm`. Is it true? Should ikiwiki support sharing its repo with other things? Mercurial-wise that sounds like a world of pain.
 
 
 The comment just below the function declaration below is taken from `git.pm`. Is it true? Should ikiwiki support sharing its repo with other things? Mercurial-wise that sounds like a world of pain.
 
+> Yes, ikiwiki supports this for git and svn. It's useful when you want
+> a doc/ directory with the wiki for a project. I don't know why
+> it wouldn't be a useful thing to do with mercurial, but it's not
+> required. --[[Joey]]
+
                {
                my $ret;
                sub hg_find_root {
                {
                my $ret;
                sub hg_find_root {
@@ -776,6 +814,10 @@ The comment just below the function declaration below is taken from `git.pm`. Is
 
 I haven't tested the attachment code below. Is it run when there is an non-trusted file upload?
 
 
 I haven't tested the attachment code below. Is it run when there is an non-trusted file upload?
 
+> It's run when an anonymous git push is done. I don't know if there would
+> be any equivilant with mercurial; if not, it does not makes sense
+> to implement this at all (this function is only used by `rcs_receive`). --[[Joey]] 
+
                                        # extract attachment to temp file
                                        if (($action eq 'add' || $action eq 'change') &&
                                                ! pagetype($file)) {
                                        # extract attachment to temp file
                                        if (($action eq 'add' || $action eq 'change') &&
                                                ! pagetype($file)) {
@@ -811,6 +853,13 @@ Also, a comment in `git.pm` mentions that we don't want to chdir to a subdir "an
 
 In this case we need to stay in default repo instead of srcdir though, so `hg_dir="."` _is_ needed, but not for the abovementioned reason :-) (maybe there's more to it, though).
 
 
 In this case we need to stay in default repo instead of srcdir though, so `hg_dir="."` _is_ needed, but not for the abovementioned reason :-) (maybe there's more to it, though).
 
+> Implementing some sort of anonymous push handling for mercurial is not something
+> you can funble your way through like this, if it can be done at all.
+> 
+> Hint: `$_` is being populated by the specific format git sends to a
+> specific hook script.
+> --[[Joey]]
+
                sub rcs_receive () {
                        my @c_infos_ret;
                        while (<>) {
                sub rcs_receive () {
                        my @c_infos_ret;
                        while (<>) {