Re: [Monotone-devel] update multiple projects

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 01.04.10 04:18, schrieb Stephen Leake:
>> Thomas Keller <address@hidden> writes:
>
> ...
> Its not a bug, its an OSX feature - 

Sorry, if it doesn't do what _I_ want (or even _need_, in this case),
it's a bug :).

> opendiff now does nothing else than packing the given command line
> arguments into an event and sends it to the system when then in turn
> opens FileMerge.app (the actual standard merger) and tells it to
> open the two files.

And it needs an option to wait until the user exits!  The command line
shell gives the user control over whether a spawned process is in the
background; that's what '&' is for. opendiff takes away that control;
that's a bug.

But we have to live with it.

>> So 'mtn au stdio' 'l6updatee' with the standard hooks does require
>> prompting via stdio, if the best available merger is opendiff. So we
>> (I) have to do something. Sigh.
>
> Really, please don't let it call the external merger - this really gets
> messy otherwise. I won't support the inclusion of this code otherwise in
> mainline, but would propose you keep that in your own private
> branch.

Ok, I'll try to come up with a better solution.

>>>> I think we need to make the value of --non-interactive available in
>>>> Lua hooks, so the user overriding a hook can check it before doing
>>>> something that might prompt.
>>>
>>> This sounds more like a workaround for a problem similar to one which
>>> you already solved quite smartly. Wouldn't be a better solution to
>>> expand show_conflicts to work in workspace mode and give mtn automate
>>> update an option --resolve-conflicts-file to resolve these on the fly?
>> 
>> Yes. But that's a lot of work, and I don't think it's worth it. I'm
>> also not sure it's possible; I have looked at the way update finds and
>> handles conflicts, and it's more complicated than for an in-database
>> merge; there are many separate stages, and you can't always back out
>> and leave a clean workspace. I'm certainly not willing to hold up
>> 'gds_update_all' for it. [...]
>
> The problem I have with all the "solutions" so far for the workspace
> merging issue is that whatever we do it ends up as hack - 

I agree that passing --non-interactive as a single flag to each hook
that might need it is a hack. I'll investigate adding a generalized
'get_option' Lua function that hooks can call; would that be better?
It doesn't meet your requirement above to not call the external
merger, but it does separate the issue of accessing options, and
handling --non-interactive, from the external merger/workspace
conflicts issues.

You seem to be saying you see the external merger itself as a "hack";
I think it's a reasonable solution to the workspace merge content
conflict problem. It just needs some help to cope with broken mergers
like opendiff.

One solution to the workspace merge general conflicts problem would be
to only let it handle simple content merge cases; fail and require
commit or revert for anything else. That would work for me; it's what
I do anyway. Then we could extend 'mtn conflicts *' to update, to
handle the case where there are lots of content conflicts.

There may be other workspace conflicts that are "simple" in the sense
that an extension to 'mtn conflicts *' could handle them.

At the risk of encouraging you, this could inspire me to take another
look at extending 'mtn conflict *' in a limited way to 'update' in its
current form. 'mtn conflict *' doesn't currently handle all
in-database merge conflicts, so not handling all workspace conflicts
would be consistent. That would at least provide a framework that
could be gradually extended.

Another solution for 'au update' would be to establish a protocol
whereby mtn sends info about a conflict to the front end, the front
end handles it, and then mtn continues. But that's very close to
prompting (it _is_ prompting when the 'front end' is a bash shell), so
I'm not sure it would work. 

Hmm. That suggests we look at exactly why 'au stdio' doesn't like
prompting; I've always just assumed that, but I'm not sure what the
actual issue is. I guess the input and output streams are not
synchronized. But a prompt is just a synchronization method (like an
Ada rendezvous, or a Java sync method), so we ought to be able to
implement something that supports it.

But I prefer asynchronous solutions like 'mtn conflicts *'.

> This is personally a blocker for me - what do other people think about
> it? 

Yes, I'd like to get some other input.

> Stephen, would it be possible for you to use a plain (non-automate)
> version of update in your gds_update_all command?

Yes, but I don't know how to do that from a Lua script; as far as I
know, the only way to execute a mtn command from Lua is via
mtn_automate.

I guess I could define LUAEXT(update). But that feels like a
different flavor of hack - it leads to a third set of implementations
for each command :(. 'mtn_automate' is much better.

-- 
-- Stephe