Re: svn commit: r8632 - trunk/tools/cvs2svn

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

[email protected] writes:
> "C. Michael Pilato" <[email protected]> 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-lmwclWVctOZK/[email protected]
> For additional commands, e-mail: dev-help-lmwclWVctOZK/[email protected]