Brane and I just chatted in IRC, and he proposed a much better idea:
marshal everything, but enclose the anydbm objects in a wrapper class
that handles the marshaling and unmarshaling, so our code isn't
cluttered with that stuff.
I *know* you're +1 on this :-).
I'll take care of it.
-K
kfogel@collab.net writes:
> "C. Michael Pilato" <cmpilato@collab.net> writes:
> > > Extend debugging tool as part of work on issue #1510:
> > >
> > > * tools/cvs2svn/dump-db.py
> > > (main): Handle unmarshalled data too.
> >
> > When I saw this, I started to revert my cvs2svn.py change of revision
> > 8547 (which started marshaling the revisions db data so dump-db.py
> > could deal with it), but it seems that some of our revision data
> > *does* look similar enough to marshaled data -- when I reverted the
> > that change locally, I actually got a SEGFAULT in Python (repeatedly,
> > not a fluke case) trying to use dump-db.py on now-unmarshaled
> > cvs2svn-revisions.db!
> >
> > I think for consistency (yes, at the cost of the marshaling), I'd
> > prefer to keep all our .db data marshalled. Besides, if we change the
> > format of those database values, we don't have to remember to start
> > marshaling it later.
>
> I've got a better idea (or anyway, I think it's a better idea): let's
> have our one-off debugging tool know the names of the files, and
> decide based on that whether to unmarshal or not.
>
> I certainly prefer that to marshalling data unnecessarily (and I'm
> happy to implement it). It's not the performance overhead of
> marshalling that bugs me, it's the unnecessary clutter in cvs2svn's
> code. I'd rather not marshal except where the data demands it.
>
> -K
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Feb 14 00:19:41 2004