On 11 June 2013 12:03, Louis des Landes <[email protected]> wrote:
> 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) > Forgive replying to myself but I've found the issue here and now wondering on API things again. First - I was correct, the issue occurred due to changes in vcview - to find the file state we call self.vc.lookup_files([], [(os.path.basename(path), path)])[1][0] The method def is def lookup_files(self, dirs, files, directory=None): Which ends up returning self._get_dirsandfiles(directory, dirs, files) For bzr, _get_dirsandfiles is currently returning everything under the current dir, not restricting to items in 'files' being passed in, and as up in vcview we just grab the first one, most of the time it's not actually checking if the file in question is conflicted but merely *a* file is conflicted. So, what is the API for _get_dirsandfiles ? What should it's return value actually be? Restricted to *only* the status of dirs and files passed to it? A quick look shows it's not just bzr which would have this issue - svn doesn't even LOOK at the dirs/files args passed to it for example, and would also return all files under directory. Hope my long-winded explanation is followable. Louis.
_______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
