Re: svn commit: r8632 - trunk/tools/cvs2svn
[email protected] 13 Feb 2004 13:35:42 -0600
| Newsgroups | gmane.comp.version-control.subversion.svn,gmane.mail.eyebrowse.devel |
|---|---|
| Message-ID | <[email protected]> |
"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