Re: Version control support call for help



On 11 June 2013 12:35, Louis des Landes <louis obsidian com au> wrote:
On 11 June 2013 12:03, Louis des Landes <louis obsidian com au> 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]