[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] ikiwiki monotone support

From: William Uther
Subject: Re: [Monotone-devel] ikiwiki monotone support
Date: Mon, 18 Feb 2008 12:25:34 +1100

On 17/02/2008, at 8:08 PM, Brian May wrote:

"William" == William Uther <address@hidden> writes:

   William> I think the "Monotone_rcs_support" bug got marked as
   William> closed and it just got forgotten about.  I haven't chased
   William> it up.  There is still more work that could be done with
   William> links to ViewMTN and making sure the commit emails work,
   William> so I wasn't too fussed that the incremental stuff didn't
   William> get committed.

I got most of the changes applied.


I am uneasy about this change though, the change for to update the
wiki from the monotone hook:;a=commitdiff;h=1c06aed378e579b7396937fdff4e38ea0482ff5b;hp=8f7d7c1a00d65fcdb1482f5e8ce334be752c3db4

It is a bit better then the original patch... which was intended to
have the monotone wrapper script in the path somewhere.

I can't remember the details.  Been too long.

Why put the hook into _MTN/mergerc instead of _MTN/monotonerc?

As such, the hook won't get used unless specified. From memory
_MTN/monotonerc is read by default.

Because the monotone stuff could specify the extra rc file when needed
and it meant that it would not conflict with a user-added rc-file.

* Could all the hooks get moved into _MTN/monotonerc?

* Or is it better just to add the note_netsync_revision_received hook
 in _MTN/monotonerc?

I confess I am not really sure what the mergerc stuff does.

ikiwiki is designed to have workspace based merges. Monotone didn't handle
that when I wrote that stuff (at least not for conflicts), so I added an
extra merge hook or two to handle that case.

First, the code commits what the user wrote. If this leads to multiple heads
then the code tries to merge them.  At that point it uses an external
merge-hook that always fails. If the internal merge works then everything
is fine.  If then the code detects that as a conflict.

In the conflict case, the code tries the merge again with a second merge
hook. The second hook uses the diff-tools to insert standard conflict markers. These conflict markers end up being committed which is not ideal, but c'est la vie. The code then updates to the 'conflicted' revision, and tells ikiwiki to tell the user that the conflict occurred and so they should be bounced back
to the editor.

Since I wrote that stuff, I believe that support has been added to the standard monotone hooks to do some of this. It may be that the rest could be added
to monotone and the merge-rc-file could go away.

For reference, the latest copy of the file is also available:;a=blob;f=IkiWiki/Rcs/;hb=HEAD

Also, related, I suspect this part of the patch might have got missed,
but before I ask Joey to fix this, I want to resolve the above. This
change may not be required.

@@ -186,8 +186,9 @@ sub rcs_update () { #{{{

       if (defined($config{mtnsync}) && $config{mtnsync}) {
+               check_mergerc();
               if (system("mtn", "--root=$config{mtnrootdir}", "sync",
-                          "--quiet", "--ticker=none",
+ "--quiet", "--ticker=none", "--rcfile", $config{mtnmergerc},
                          "--key", $config{mtnkey}) != 0) {
                       debug("monotone sync failed before update");

Not sure that bit is required. I was just going through and adding the -rcfile arg to everything so that if more got added there in future it wasn't confusing that it was only being referenced
in some places.


Will         :-}

reply via email to

[Prev in Thread] Current Thread [Next in Thread]