monotone-devel
[Top][All Lists]
Advanced

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

Re: [Monotone-devel] update multiple projects


From: Thomas Keller
Subject: Re: [Monotone-devel] update multiple projects
Date: Thu, 01 Apr 2010 09:44:20 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4

Am 01.04.10 04:18, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
> 
>> Currently, whether you do a normal or a
>> workspace merge, as soon as a content conflict arises, mtn opens a
>> merger process (might it be vim or kdiff3 or emacs or opendiff) and
>> waits until this process ends, i.e. returns, to pick up the saved
>> temporary file afterwards.
>> The problem is now that the shell call which opens the merger
>> process has to _block_ until the process actually ends, 
>> if it spawns in the background and returns immediately, 
> 
> Why would it do this? Sounds like a bug in the merger hook, or the
> merge tool, to me.

Its not a bug, its an OSX feature - simply put it doesn't matter if you
open a file or an application on Mac OS X, for both cases an
asynchronous event is fired which is handled by the system. If the app
which should be started is already running, the app gets a file open
event, otherwise it is first started and then immediately gets a file
open event (there is no standard way to define command line variables,
i.e. arguments to a bundled application, as long as you don't want to go
into its internals, you usually use the `open` call for that).
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.

>> mtn cannot pick up the temp file and therefor not the manual merge
>> result. Thats why it waits for a key stroke from the user to act
>> upon further. And this is actually the default behaviour for the
>> default merger "opendiff" on Mac OS X...
> 
> I see that code in std_hooks.lua mergers.opendiff. I'd call this a bug
> in opendiff. But I'm not volunteering to fix 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.

>>> 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 - which in turn
adds another layer of complexity into an already complex setup. I'd
rather see a good solution some time than a bad solution tomorrow,
because the bad solution has to be supported from the remaining
developers by the day it wents into mainline (and there are not so many
of us left as you might know).

This is personally a blocker for me - what do other people think about
it? Stephen, would it be possible for you to use a plain (non-automate)
version of update in your gds_update_all command?

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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