Re: Conversion of Perl Perforce repository to Subversion - Part 1

Barrie Slaymaker wrote:
> I hope that you're not trying to use the VCP::Dest::revml driver for
> serious conversions.  Even if it didn't hog up a log of disk space,
> going to RevML and then away from RevML is going to be terribly slow.

No, I was just generalizing, since I don't know how CLKao developed his module. 
 I want to use VCP::Dest::svk, but I needed a way to tell whether the RAM usage 
was on the VCP side or the svk side.

> If you want to send me a copy of the perl repository, I can work with it
> here to narrow in on the problem; the core VCP filters and {p4,vss,cvs}
> drivers need to be RAM friendly.

I cannot send you the Perl repository, unfortunately.  Sarathy has given me a 
readonly account on the server, but I don't think that makes it possible for me 
to copy it (except by using VCP, of course ;).

> You can try using the null: destination and (first) no filter, then
> (second and later) the filters VCP reports using in its log file on the
> p4->svn conversion to isolate the RAM usage.

This seems a more profitable line of inquiry.  I'll try and fire off a null copy 
this weekend.  I am confused by your second step; how do I toggle the filter 
usage on and off?

> By far the most common data structure is the VCP::Rev object, so tracing
> the lifecycle of VCP::Rev instance is likely to turn up some
> information.  In order to conserve memory, however, this is a packed
> data structure in memory and a lot of the standard strings are stored in
> tied hashes so that VCP::Rev instances can contain ints.  Forcing a
> coredump and looking at it with the strings command might be informative
> (in case I forgot to tie a hash).

I can give that a shot too.  How do I force a coredump?

John

--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747