On 1 July 2010 01:00, Eric Lake <[email protected]> wrote: > On Mon, Jun 28, 2010 at 5:24 AM, Kai Willadsen <[email protected]> > wrote: >> >> So there are a couple of different problems here. >> >> Firstly, we use an overly-simplistic test for whether a given >> directory is actually a repository; this isn't unique to bzr. We >> *could* fairly easily establish better tests (e.g., run bzr status and >> check whether we get an error) but if we do this for each VC, it's >> likely to be really slow. Maybe a mixed approach (e.g., stat for .bzr, >> then run bzr status) would be in order. >> >> The second problem is that we don't check to see whether we have the >> appropriate tools installed for a given repository. Correct behaviour >> here would probably be to see if we can find the binary, and if we >> can't, desensitize the relevant entry in the VC selector. >> >> Patches or more detailed suggestions for either of the above would be >> gratefully accepted; failing that, could you please file bugs? >> >> cheers, >> Kai >> > > Do you know of a way other than rebooting the affected system that > will clear it up until we can upgrade?
I actually haven't been able to reproduce the problem locally. Meld 1.2 is now really quite old, and most of the related code has changed significantly in the meantime, so I'm not sure I can suggest anything other than upgrading. > It seems to get stuck thinking > that the .bzr dir is still there even when it isn't. Is something > getting cached elsewhere in the users $HOME that I can clear to > prevent the reboot? As far as I know, we don't (and in the past, didn't) cache any VC-related information at all. cheers, Kai _______________________________________________ meld-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/meld-list
