Re: Meld 1.7.1 released



On Wed, Apr 3, 2013 at 10:20 PM, Kai Willadsen <kai willadsen gmail com> wrote:
On 3 April 2013 08:16, Angel Ezquerra <angel ezquerra gmail com> wrote:
On Tue, Apr 2, 2013 at 10:10 PM, Kai Willadsen <kai willadsen gmail com> wrote:
On 3 April 2013 06:06, Angel Ezquerra <angel ezquerra gmail com> wrote:
On Tue, Apr 2, 2013 at 9:50 PM, Kai Willadsen <kai willadsen gmail com> wrote:
On 3 April 2013 02:01, Keegan Witt <keeganwitt gmail com> wrote:
I exceeded my Dropbox public folder limits, the new home for them is here:
https://meld-installer.googlecode.com/files/meld-0.0.0.0.exe
https://meld-installer.googlecode.com/files/meld-0.0.0.0.zip
I'll keep these around permanently and periodically update them with the
latest from Git master.  I include the .git directory, so you can do a git
pull on the meld directory at any time if you want to update it yourself.

This seems like an important issue to get fixed.  Do you think it'd be
appropriate to push out another release sooner rather than later?

Yeah, could do. I'll see if I can find time this weekend for it. For
that to happen, I'd appreciate any testing that people might want to
throw at current git. Several Windows-related fixes went in over the
weekend for Git actions, temp files and executable locating, and it
would be nice if they worked for someone other than me.

cheers,
Kai

There is a serious issue on Windows that we've been discussing on the
mercurial-devel mailing list, which is that meld returns 0 even if you
do not save the merge output (i.e. if the merge fails). This makes
mercurial believe that the merge was successful when it isn't.

For now we are thinking of enabling mercurial's "checkchanged" option
for meld, which means that mercurial will check if the merge output
changed once meld exits, and ask the user if the merge failed if it
did not. That is a band-aid though, so improvements on that area would
be really great.

I think Keegan is aware of that issue. Something related to portable python?

Not a portable python problem I think. We don't ever (to my
recollection) change return values. I'm not sure that it makes sense
to do so either, since there's no way to indicate multiple returns
(i.e., tabs 1 and 3 were saved but tab 2 wasn't). I realise that
launching multiple merges isn't a common case, but... it just feels
wrong to me.

Could you explain why you consider the checkchanged option to be a band-aid?

cheers,
Kai

It is a band-aid because we only use that option when the tool is not
able to tell us that the merge was successful. Most merge tools do
tell us when a merge succeeded by returning a 0 exit code, and when
the merge fails with a non zero exit code. This allows us to do the
merge pretty much automatically. If the merge tool does not return a
non zero exit code when the merge is aborted by the user then we can
only guess, and we do so by checking if the merge file contents
changed, which is not very accurate. If they did not change we must
ask the user to confirm that the merge was successful, which adds an
additional prompt.

So as you see it is less than ideal. One of the main mercurial devs,
while discussing the need to use the checkchanged setting said "That's
a very serious issue", and I agree with him.

What I don't understand is how you expect *Meld* to know whether the
merge was successful? I mean, it's pretty easy to exit(1) if the user
doesn't save the merge file, but I don't see how that's significantly
more accurate than checking the file contents on the Mercurial side?

It is more accurate because it relies on an explicit action from the user:

- If the user is happy with the result of the merge, it saves it
(which is natural, what else could it do?)
- If he is not happy with hit, he just does not save it and closes the
merge tool
   - If he did do some changes to the merge panel and he tries to exit
without saving, the tool could warn him and ask him to confirm.

Without this, mercurial (or git, or whatever) must guess what
happened. If the file changed we an only assume that the user saved it
so he must be happy with it. If the file did not change... we don't
know because maybe the result of the merge is just not changing the
file.

FWIW, I believe that all the other merge tools that I've used with
mercurial (notably Araxis Merge, KDiff3, WinMerge and CodeCompare)
work this way.

As I see it, the only other option is to require the user to click a
"Yep, I resolved this" button, which is functionally the same as a
command-line prompt saying "How did the merge go?".

BTW, if I understood you correctly, this is non windows specific, right?

I haven't actually checked behaviour, but yes. There is no sensible
way right now for us to set a return code based on a single
comparison, simply because a window can contain multiple comparisons,
and we would have no idea what to return.

I think that meld could handle the situation that you mention by
returning 0 if the user saves any of the files, and non zero
otherwise.

That sounds exceedingly dangerous. If you open up two merges and only
save one of them, then you're giving back a false positive, which is
much scarier than saying that a merge failed when it didn't really.

I think I misundestood you. I thought you were talking about what
happens if the user saves any of the non output panels. Now I think
that you are talking about what happens when the user has more than
one diff tab open?

If so I agree that is a tricky situation. In the case of Mercurial I
believe it will always ask you to merge one file at a time, so this
could not really happen. In that case, even if the user opened another
diff tab meld could just take into account what happens on the first
diff tab in order to decide its exit code.

Another option would be to only return 0 if the output file
(as specified with the -o parameter) is saved.

Same as above I think.

Again, I was referring to the behavior if the user saves more than one
of the files on _one_ panel. In that case I thin that just checking
what happens on the output / merge panel would be the right thing to
do.

What do you think?

I'm certainly not averse to making changes to make Meld more usable by
Mercurial, but it has to not break current Meld use. At this stage, it
sounds to me like Mercurial (and maybe other systems? I don't know)
would like Meld to have a completely different mode from the normal
user-invoked one. Off the top of my head:

 * Disallow creation of new tabs
 * Disallow re-use of an existing instance
 * Add exit code based on 'success of merge' (whatever that means)
 * Some UI to indicate merge success?
 * Remove file selectors, replacing them with labels

...all of which is doable. It's just work. If there's anyone lurking
who is involved in mergetool configurations for Git or Bazaar or
whatever, now would be a good time to speak up.

All of those would be great. That being said I don't think meld needs
to do all that to inter-operate well with an external VCS. IMHO just
setting the exit code based on whether the output panel of the first
diff tab would take us 80% of the way there. Improving the labels
would get us another 15%. The rest would be the icing of the cake :-)

Cheers,

Angel


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