Re: [Monotone-devel] ikiwiki monotone support

[William Uther]

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
either...

>    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();
> 192
> 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         }
> 200
> 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 Stub.pm 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
> branches...

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
monotone.pm file where the rest of the mergerc file is stored.

Be well,

Will        :-}