On Tue, 2008-01-29 at 11:35 +0000, Robert Collins wrote:
> On Mon, 2008-01-28 at 22:28 +0000, James Westby wrote:
> > Hi,
> >
> > Thanks for your bug report.
> >
> > I am interested in what is causing the problem that you are
> > seeing. From the traceback I would guess that it is using a
> > lot of memory to read the dirstate (the on disk representation
> > of the state of the working tree).
>
> Actually, I suspect its a corrupt dirstate; using the non C version of
> the dirstate parser will likely work better and give a better message.
Michael, in order to test this, could you please either delete or rename
/usr/lib/python2.5/site-packages/bzrlib/_dirstate_helpers_c*
This will mean that the python versions are used instead, hopefully
giving us some more information.
Everyone else, Is it worth adding an environment variable to override
the C versions and use the python versions for testing this sort of
thing in future?
On Tue, 2008-01-29 at 11:35 +0000, Robert Collins wrote:
> On Mon, 2008-01-28 at 22:28 +0000, James Westby wrote:
> > Hi,
> >
> > Thanks for your bug report.
> >
> > I am interested in what is causing the problem that you are
> > seeing. From the traceback I would guess that it is using a
> > lot of memory to read the dirstate (the on disk representation
> > of the state of the working tree).
>
> Actually, I suspect its a corrupt dirstate; using the non C version of
> the dirstate parser will likely work better and give a better message.
Michael, in order to test this, could you please either delete or rename python2. 5/site- packages/ bzrlib/ _dirstate_ helpers_ c*
/usr/lib/
This will mean that the python versions are used instead, hopefully
giving us some more information.
Everyone else, Is it worth adding an environment variable to override
the C versions and use the python versions for testing this sort of
thing in future?
Thanks,
James