I'll have a look at this after I finish wading through the bzr changes. I think it's particularly important for things such as push and pull - silent failures are bad.
-- Louis On 12 June 2013 06:21, Kai Willadsen <[email protected]> wrote: > On 11 June 2013 12:03, Louis des Landes <[email protected]> wrote: > <snip> > > On 10 June 2013 09:33, Kai Willadsen <[email protected]> wrote: > >> 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? > > Unfortunately we can't. Some VCs *love* to dump stuff to stderr, even > when there wasn't an actual problem (*ahem* Git), presumably on the > basis that even if you've redirected stdout somewhere you'll still see > it. I think we need to do what you suggested and check the error code, > raising some kind of notification (maybe just an infobar) if we get an > error response. > > cheers, > Kai >
_______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
