On 11 June 2013 12:35, Louis des Landes <[email protected]> wrote: > On 11 June 2013 12:03, Louis des Landes <[email protected]> wrote: >> 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 ?
Yes. > What should it's return value actually be? Indeed. > Restricted to *only* the status of dirs and files passed to it? Who can say? > 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. Oh, it's definitely followable. Your confusion is 100% warranted. I think you're starting to see why I'm so scared of our VC subsystem. We don't have a documented API. Even if we *did* have an API, most of these modules were created by someone copying another module and munging things until they worked. So even if there was originally an implicit API, it's long since died and we're left with a hunk of stuff that mostly works but OH GOD DON'T TOUCH IT. So when I say that we should leave this stuff working the way it works now and come up with a *completely new parallel API* that makes sense... this is why. cheers, Kai _______________________________________________ meld-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/meld-list
