I've pushed up a bunch of the smaller fixes to bzr as bug reports. https://bugzilla.gnome.org/show_bug.cgi?id=701970 https://bugzilla.gnome.org/show_bug.cgi?id=701971 https://bugzilla.gnome.org/show_bug.cgi?id=701972 https://bugzilla.gnome.org/show_bug.cgi?id=701973
There's some changes to how the caching is managed which remain - Current HEAD has actually broken 3 way on concflict for bzr due to _vc caching changes (possibly related to the changes made on how it's called if there's no cache - required for the svn update we did) On 10 June 2013 09:33, Kai Willadsen <[email protected]> wrote: > > Related - what happens with the return code from the runner with push / > pull > > etc? > > After adding them to bzr, if it fails, it fails silently. > > Yeah, these aren't checked yet. All my API playground did was move the > execution control into the VC module. It would be great to have a plan > that made sense for error reporting for errors from VC modules. A bit of a look through, these are passed down to the scheduler, which stores the error output on a consolestream object (self.consolestream on the vcview) I would have thought if we get output on stderr we should be raising a the dialog - but this only actually happens if there's an IOError (ie something gets screwed up with the pipes themselves, not that the stderr pipe contains an error) Should this behaviour be changed perhaps?
_______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
