[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: Thu, 21 Feb 2008 21:46:32 +1100

On 21/02/2008, at 8:32 PM, Brian May wrote:

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

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.

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

Ok, I can see the reason now.

It does mean though if I sync to that database outside of ikiwiki, I
have to manually add the _MTN/mergerc file, or the
note_netsync_revision_received hook won't take affect.

Um, syncing to a database is not going to call a hook in _MTN/monotonerc

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

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

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

I guess what you really need here is a "manual" merge method.

Well, workspace based merge.

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

Hmm. Any references?

Look in the standard lua hooks in the monotone source. The diff utils merge system has become significantly more featureful. I think it would be possible to have my 'add conflict markers' merge hook be just an argument there, but I
haven't looked at it in detail.

On 21/02/2008, at 8:37 PM, Brian May wrote:

190 sub rcs_update () { #{{{
191         check_config();
193         if (defined($config{mtnsync}) && $config{mtnsync}) {
194 if (system("mtn", "--root=$config{mtnrootdir}", "sync",
195                            "--quiet", "--ticker=none",
196                            "--key", $config{mtnkey}) != 0) {
197 debug("monotone sync failed before update");
198                 }
199         }
201 if (system("mtn", "--root=$config{mtnrootdir}", "update", "--quiet") != 0) {
202                 debug("monotone update failed");
203         }
204 } #}}}

I can't help but feel this seems wrong.

In particular, it might be better without the mtn sync.

Presumably, rcs_update will be called automatically after a "mtn pull"
has occurred, by the hook, making this redundant.

er, no. I believe that rcs_update() is called by ikiwiki when it wants ikiwiki to update the workspace. Look at the comments in the example code in ikiwiki:

sub rcs_update () {
        # Update working directory to current version.
        # (May be more complex for distributed RCS.)

In particular, Ikiwiki knows nothing of a "mtn pull" and isn't doing it for us somewhere else. The monotone equivalent of a traditional 'svn up' is something like 'mtn pull ; mtn up'. You need the pull, at least as an option (which it
is - the 'mtnsync' config option allows the user to turn off the pull if
they don't want it).

Also, having rcs_update do a mtn push operation just seems wrong to
me. The push occurs after a commit...

It doesn't explicitly 'push'.  It does 'sync' instead of 'pull' though.
That is redundant, yes. I don't see it hurting though. You could switch it to a 'pull' instead of a 'sync' if you want. I think I switched it to a sync before I
added the --key option to make it connect with the correct key.

The "mtn update" seems fine though. Assuming there aren't multiple

The "mtn update" is what ikiwiki is calling that function for. It isn't 'fine'; it's whole point of that function! Multiple branches has nothing to do with this.

I just went and had a quick look at the current source. In check_mergerc(), why has the mergerc file text been split into two places - the main block of text at the end of the perl file, and a smaller block that gets added in check_mergerc()? I'd just move the lua code for note_netsync_revision_received() to the end of the file where the rest of the mergerc file is stored.

Be well,

Will        :-}

reply via email to

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