[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: <kfogel_at_collab.net>
Date: 2004-02-13 20:35:42 CET

"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.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Feb 13 21:37:07 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.