On 30 June 2013 21:57, Gilboa Davara <[email protected]> wrote: > On Thu, Jun 27, 2013 at 11:53 PM, Kai Willadsen <[email protected]> > wrote: >> >> On 28 June 2013 00:44, Gilboa Davara <[email protected]> wrote: >> > On Thu, Jun 27, 2013 at 5:21 PM, Chuck Tuffli <[email protected]> wrote: >> >> I suspect this is the same issue Kai fixed recently for me. Give a >> >> directory structure like: >> >> >> >> a/ >> >> b/foo.c >> >> c/bar.c >> >> >> >> meld would generate the error you mention if both foo.c and bar.c had >> >> modifications. The fix (e79f5611799d0cd88e8ec630b699d9027503a45c I >> >> think) in git fixed the problem I was seeing. >> >> >> >> --chuck >> > >> > I rather not pull git right now. >> > >> > Kai, >> > >> > Just to be certain: Should I simply comment out >> > self.vc.uncache_inventory() in _search_recursively_iter? >> >> Chuck is right, this looks like exactly the same problem. So yeah, >> that's what I'd try. >> >> The behaviour this change fixes is that running a comparison in a >> different subdirectory to the first comparison that's run, breaks. >> >> cheers, >> Kai > > Seems to work just fine. > Thanks. > > Should I contact the Fedora meld maintainer and get the fix applied to > the official package, or should I simply wait for 1.7.4?
I think that that's a fairly low-risk patch for a real issue... so yes, trying to get it into the 1.7.3 fedora package would be a good idea. I think 1.7.4 has most of the remaining breaking changes for the 1.7.x cycle, so after that things should calm down. cheers, Kai _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
