gdbm has fewer restrictions on the data sizes than ndbm. The licensing isn't
all that great (GPL rather than LGPL), but it is definitely a better dbm
implementation.
Since it is working fine on your RedHat box (where Python will build its
gdbmmodule), then I'd suggest that it *is* related to ndbm. What exactly the
problem is... hard to say.
What would help is a copy of the ,v file which causes the problem. It is
sometimes hard to figure out which file, exactly, created the problem, but
it seems to be located in webcenter/prod/htdocs/aams/. cvs2svn can convert a
single subtree, so if you can cut the tree down to just a single directory
or even a single file, then (hopefully) we can repro it locally. (not sure
how sensitive your files are; either post or mail directly to kfogel; if
neither are possible, then things will be quite difficult :-).
Cheers,
-g
On Tue, Jul 01, 2003 at 03:30:28PM -0600, Johnson, Graham wrote:
> On RedHat, cvs2svn is chugging along fine on my repository, currently
> being several passes "------- Committed revision 2798 >>>..." beyond
> where it was failing on the Solaris machine.
>
> Assuming the repository will be portable between Linux and Solaris, I
> can accept doing migrations (for testing and presumably for an eventual
> final migration) on the Linux machine and moving the repository.
>
> I'm willing to provide any assistance/information needed to figure out
> why it is failing on the Solaris machine. We don't know, though, that
> the problem isn't specific to this one machine or to how I installed
> things.
>
>
> --
> Graham Johnson
> gjohnson@alpineaccess.com
>
> -----Original Message-----
> From: kfogel@collab.net [mailto:kfogel@collab.net]
> Sent: Tuesday, July 01, 2003 2:20 PM
> To: Johnson, Graham
> Cc: dev@subversion.tigris.org
> Subject: Re: Cvs2svn dies with "dbm.error: cannot add item to database"
>
>
> "Johnson, Graham" <gjohnson@alpineaccess.com> writes:
> > Below is the version info. This is Solaris 8; I suspect the dbm
> > implementation isn't as good as what cvs2svn is used to.
> >
> > I tried last week to build Python using gdbm instead of ndbm, but I
> > don't think I did it right. It still failed, though slightly
> > differently (dbm_error returned 0 instead of 2). Do you know anything
>
> > about getting Python to use a different dbm implementation? Can it be
>
> > made to use Berkeley DB?
>
> I don't offhand, but maybe someone here does (or check the docs at
> python.org, they're very thorough.)
>
> What I'm mainly interested in is determining exactly which db is causing
> a problem and why, so cvs2svn.py can somehow test for it...
>
> > We do have a linux box here (RedHat 8), so I'm going to try to install
>
> > svn on that and try it there. I'll let you know how it goes.
>
> Thanks.
>
> > 1546 : ~/downloads/Unix/svn/tools/cvs2svn>grep LastChangedRevision
> > cvs2svn.py # $LastChangedRevision: 6360 $
>
> A little bit behind HEAD, but not significantly so.
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 2 00:33:16 2003