On Mon, Jul 1, 2013 at 12:13 AM, Kai Willadsen <[email protected]> wrote: > 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
Somehow I missed your response. FWIW, Fedora BZ https://bugzilla.redhat.com/show_bug.cgi?id=986671 - Gilboa _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
