[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
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 :-}
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/17
- Re: [Monotone-devel] ikiwiki monotone support, William Uther, 2008/02/17
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/21
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/22
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/22
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/22
- Re: [Monotone-devel] ikiwiki monotone support, William Uther, 2008/02/24
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/25
- Re: [Monotone-devel] ikiwiki monotone support, William Uther, 2008/02/24
- Re: [Monotone-devel] ikiwiki monotone support, Brian May, 2008/02/25
- Re: [Monotone-devel] ikiwiki monotone support, Zack Weinberg, 2008/02/25